AU2021218208A1 - Systems and methods for reducing unwarranted transaction refusals - Google Patents

Abstract

The present disclosure provides systems and methods which can be configured to identify services that may be of use or interest to a card holder (for example, unlocking a transaction card and/or alternative services) and interrupt a card not present transaction (CNP) in order to provide such services to the card-holder. In particular, the present disclosure is directed to a computer implemented method comprising: receiving an authentication request in relation to a card not present transaction, the authentication request being a request for authentication of a transaction with a merchant using a transaction card associated with a cardholder, the authentication request including transaction card data relating to the transaction card; determining, using the transaction card data, if the transaction card is locked; in response to determining that the transaction card is locked, causing a card locked notification to be presented at an electronic device of the cardholder; receiving a card locked notification response from the electronic device; and in response to the card locked notification response being an unlock card response: unlocking the transaction card; and completing the authentication request. 1003624049 1/6 Issuing bank server system 110 100 Issuing bank server application 112 Merchant server system120 Issuing bank data store 114 Merchant server application 122 Services application 116 User device 130A 102 User device139]B Merchant client Issuing bank client application application Third party server system 140 2FA application 142 Figure 1

Description

1/6

Issuing bank server system 110 100

Issuing bank server application 112 Merchant server system120 Issuing bank data store 114 Merchant server application 122 Services application 116

User device 130A 102 User device139]B

Merchant client Issuing bank client application application

Third party server system 140 2FA application 142

Figure 1

I SYSTEMS AND METHODS FOR REDUCING UNWARRANTED TRANSACTION REFUSALS FIELD OF THE INVENTION

[0001] The present disclosure relates to systems and methods for reducing unwarranted transaction refusals.

BACKGROUND OF THE INVENTION

[0002] Customers are increasingly shifting their pattern of behaviour towards paying for purchases online. This type of transaction is typically referred to as a card not present (CNP) transaction. CNP transactions are typically at higher risk of fraudulent activity, which may occur when compromised transaction card (e.g. credit, debit, travel money, or other transaction card) details are entered at the online merchants' checkout without the cardholder's knowledge or permission.

[0003] Various mechanisms for combatting CNP fraud exist, some implemented by cardholders themselves (via applications or interaction with their financial institution), some implemented by financial institutions (e.g. banks), some by payment network schemes (e.g. Mastercard/Visa), some by merchants.

[0004] In some cases, the existence of multiple fraud mechanisms running in parallel can result in transactions that a cardholder wishes to proceed - and, moreover, thinks they have approved - being declined. A legitimate transaction (i.e. one that a card holder does wish to be processed) being declined can lead to a number of undesirable consequences. These range from unnecessary and increased data processing (e.g. where the cardholder must re-initiate a transaction, which may cause additional processing load at a cardholder device, a merchant system, and/or a financial institution system), additional network traffic (between the various systems involved in a transaction), abandoned purchases (where a cardholder elects not to reinitiate a transaction), and an unsatisfactory user experience (potentially for cardholders, merchants, and/or financial institutions).

[0005] Reference to any prior art in the specification is not an acknowledgment or suggestion that this prior art forms part of the common general knowledge in any jurisdiction or that this prior art could reasonably be expected to be understood, regarded as relevant, and/or combined with other pieces of prior art by a skilled person in the art.

z

SUMMARY OF THE INVENTION

[0006] According to an aspect of the invention, there is provided a computer implemented method comprising: receiving an authentication request in relation to a card not present transaction, the authentication request being a request for authentication of a transaction with a merchant using a transaction card associated with a cardholder, the authentication request including transaction card data relating to the transaction card; determining, using the transaction card data, if the transaction card is locked; in response to determining that the transaction card is locked, causing a card locked notification to be presented at an electronic device of the cardholder; receiving a card locked notification response from the electronic device; and in response to the card locked notification response being an unlock card response: unlocking the transaction card; and completing the authentication request.

[0007] According to a second aspect of the invention, there is provided computer implemented method comprising: receiving an authentication request in relation to a card not present transaction, the authentication request being a request for authentication of a transaction with a merchant using a transaction card associated with a cardholder, the authentication request including transaction data relating to the card not present transaction; determining one or more services to offer to the cardholder using the transaction data; causing offers in respect of the one or more services to be presented at an electronic device of the cardholder.

[0008] According to a third aspect of the invention, there is provided a computer processing system comprising: a processing unit; a communication interface; and non-transitory computer readable storage medium storing instructions, which when executed by the processing unit, cause the processing unit to perform a method according to the first and/or second aspect.

[0009] According to a fourth aspect of the invention, there is provided a non-transitory storage medium storing instructions executable by a processing unit to cause the processing unit to perform a method according to the first and/or second aspect.

[0010] 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 additives, components, integers or steps.

[0011] 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

[0012] Preferred embodiments of the present invention are described, by way of examples only, with reference to the accompanying figures, wherein:

[0013] FIG. 1 is a block diagram of a networked environment according to aspects of the present disclosure.

[0014] FIG. 2 is a block diagram of a computing system which may be configured to implement various features and embodiments of the present disclosure.

[0015] FIG. 3 is a flowchart illustrating operations involved in a transaction processing method.

[0016] FIG. 4 is a flowchart illustrating operations involved in an unlock card service.

[0017] FIG. 5 is an example of a card locked notification displayed on a user device.

[0018] FIG. 6 is a flowchart illustrating operations involved in a foreign exchange notification service.

[0019] FIG. 7 is an example of a currency notification displayed on a user device.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0020] The present disclosure provides systems and methods for identifying card not present (CNP) transactions which are subject to multiple anti-fraud mechanisms and which require multiple card holder actions to be taken in order for the transaction to be able to proceed.

[0021] As one example, one anti-fraud mechanism may be a requirement for the cardholder to provide two-factor authentication (2FA) and another anti-fraud mechanism may be a requirement for a cardholder to unlock a particular transaction card (e.g. credit, debit, travel money, or other transaction card) that is to be used for the transaction.

[0022] More generally, the present disclosure provides systems and methods which can be configured to identify services that may be of use or interest to a card holder (for example, unlocking a transaction card and/or alternative services) and interrupt a CNP transaction in order to provide such services to the card-holder.

Example networked environment

[0023] Figure 1 illustrates an example environment 100 in which embodiments and features of the present disclosure are implemented. Example environment 100 includes a communications network 102 which interconnects an issuing bank server system 110, a merchant server system 120, a user device 130A, a user device 130B, and a third party server system 140.

[0024] In this example, the issuing bank server system 110 includes an issuing bank server application 112 (bank server application 112 for short), an issuing bank data store 114 (data store 114 for short), and a services application 116.

[0025] The data store 114 is used for storing data related to functions performed by the issuing bank server system 110, for example, cardholder data, transaction data, and/or any other relevant data.

[0026] The services application 116 is an application (or a set of applications) responsible for offering one or more services to a cardholder. Although Figure 1 illustrates a single services application 116, the services application 116 could be multiple applications (running on the same or different physical systems), with each application being responsible for a different service that is provided by the issuing bank server system 110.

[0027] The server application 112 configures the issuing bank server system 110 to provide server side functionality for client applications (e.g. bank client application 134 discussed below). Generally speaking, this involves receiving and responding to requests from bank client applications (e.g. bank client application 134). The bank server application 112 may be a web server (for interacting with web browser clients) or an application server (for interacting with dedicated application clients). While issuing bank server system 110 has been illustrated with a single bank server application 112, it may provide multiple bank server applications (e.g. one or more web servers and/or one or more application servers).

[0028] The bank server application 112 may also provide server side functionality to other clients (e.g. merchants, card issuing schemes, etc.). While Figure 1 illustrates a single bank server application 112, it will be appreciated that there may be separate bank server applications, for example, one to provide server side functionality for client applications (e.g. bank client application 134) and another to provide server side functionality to other clients (e.g. merchants, card issuing schemes, etc.).

D

[0029] In certain embodiments, the issuing bank server system 110 is a scalable system. Depending on demand from clients (and/or other performance requirements), compute nodes can be provisioned/de-provisioned on demand. As an example, if there is high client demand additional bank server applications 112 may be provisioned to cater for that demand. In this case, each functional component of the issuing bank server system 110 may involve one or several applications running on the same or separate computer systems, each application including one or more application programs, libraries, APIs or other software that implements the functionality described herein.

[0030] In this example, merchant server system 120 includes a merchant system server application 122 (merchant server application 122 for short). The merchant server application 122 configures the merchant server system 120 to provide ecommerce services - e.g. allowing a cardholder (via client application 132 discussed below) to browse/search for goods/services, select goods/services, and purchase goods/services. Generally speaking, this involves receiving and responding to requests from clients (e.g. merchant client application 132). Merchant server application 122 may be a web server (for interacting with web browser clients) or an application server (for interacting with dedicated application clients). While merchant server system 120 has been illustrated with a single merchant server application 122 it may provide multiple servers (e.g. one or more web servers and/or one or more application servers).

[0031] In certain embodiments, the merchant server system 120 is a scalable system. Depending on demand from clients (and/or other performance requirements), computer nodes can be provisioned/de-provisioned on demand. As an example, if there is high client demand additional merchant applications 122 may be provisioned to cater for that demand. In this case, each functional component of the merchant server system 120 may involve one or several applications running on the same or separate computer systems, each application including one or more application programs, libraries, APIs or other software that implements the functionality described herein.

[0032] In this example, user device 130A includes a merchant client application 132, which, when executed by the user device 130A (e.g. by a processing unit such as 202 described below), configures the user device 130A to allow the user to access the merchant server system 120 to browse/search for goods/services, select goods/services, and purchase goods/services. This involves communicating with the merchant server system 120 (and, in particular, the merchant server application 122). The merchant client application 132 may be a web browser or a native/dedicated application installed on the user device 130A.

[00331 In this example, user device 130B includes a bank client application 134, which, when executed by the user device 130B (e.g. by a processing unit such as 202 described below), configures the user device 130B to provide issuing bank functionality to allow the user to perform banking tasks. This involves communicating with the issuing bank server system 110 (and, in particular, the bank server application 112). The bank client application 134 may be a native/dedicated application installed on the user device 130B.

[0034] In some instances, a single client device (e.g. user device 130A and/or user device 130B) may include both a merchant client application 132 and a bank client application 134. In the description below, user device 130A will be described as communicating with the merchant server system 120 and user device 130B will be described as communicating with issuing bank server system 110, though, as noted, user devices 130A and 130B may, in fact, be the same device.

[0035] In the present example, while a single user device 130A and a single user device 130B has been depicted, environment 100 will typically include multiple user devices 130A and multiple user devices 130B, each configured to interact with the issuing bank server system 110 and/or the merchant server system 120. User device 130A and user device 130B may be any form of computing device. Typically, user device 130A and user device 130B will be personal computing devices - e.g. a desktop computer, laptop computer, tablet computer, smart phone, or other computing device.

[0036] Communications between the various systems in environment 100 are via the communications network 102. Communications network 102 may be a local area network, public network (e.g. the Internet), or a combination of both.

[0037] As described below, the present disclosure involves card not present transactions which are subjected to two-factor authentication (2FA). One example of 2FA is the 3-D Secure protocol. A 2FA mechanism may be coordinated by a third party server system 140 (or set of systems) that the issuing bank server system 110 and merchant server system 120 communicate with, for example over communications network 102. In the context of the 3-D Secure protocol, this third party server system 140 is referred to as the directory server and forms part of the interoperability domain.

[0038] The third party server system 140 may have a 2FA application 142 that configures the third party server system 140 to provide 2FA services for CNP transactions. This may involve communicating with the issuing bank server system 110 and the merchant server system 120.

While third party server system 140 has been illustrated with a single 2FA application 142 it may provide 2FA services via multiple applications running on multiple servers.

[0039] While environment 100 has been provided as an example, alternative system environments/architectures are possible.

[0040] The features and techniques described herein are implemented using one or more computer processing systems. For example, in networked environment 100 described above, user device 130A and user device 130B are computer processing systems (for example, a personal computer, tablet/phone device, or other computer processing system). Similarly, the various functions performed by the issuing bank server system 110 and the merchant server system 120 are performed by one or more computer processing systems (e.g. server computers or other computer processing systems).

Example computer processing system

[0041] FIG. 2 provides a block diagram of a computer processing system 200 configurable to perform various functions described herein. System 200 is a general purpose computer processing system. It will be appreciated that FIG. 2 does not illustrate all functional or physical components of a computer processing system. For example, no power supply or power supply interface has been depicted, however system 200 will either carry a power supply or be configured for connection to a power supply (or both). It will also be appreciated that the particular type of computer processing system will determine the appropriate hardware and architecture, and alternative computer processing systems suitable for implementing features of the present disclosure may have additional, alternative, or fewer components than those depicted.

[0042] Computer processing system 200 includes at least one processing unit 202. The processing unit 202 may be a single computer processing device (e.g. a central processing unit, graphics processing unit, or other computational device), or may include a plurality of computer processing devices. In some instances, where a computer processing system 200 is described as performing an operation or function all processing required to perform that operation or function will be performed by processing unit 202. In other instances, processing required to perform that operation or function may also be performed by remote processing devices accessible to and useable by (either in a shared or dedicated manner) system 200.

[0043] Through a communications bus 204, the processing unit 202 is in data communication with a one or more machine readable storage (memory) devices which store instructions and/or data for controlling operation of the processing system 200. In this example system 200 includes a system memory 206 (e.g. a BIOS), volatile memory 208 (e.g. random access memory such as one or more DRAM modules), and non-volatile memory 210 (e.g. one or more hard disk or solid state drives).

[0044] System 200 also includes one or more interfaces, indicated generally by 212, via which system 200 interfaces with various devices and/or networks. Generally speaking, other devices may be integral with system 200, or may be separate. Where a device is separate from system 200, connection between the device and system 200 may be via wired or wireless hardware and communication protocols, and may be a direct or an indirect (e.g. networked) connection.

[0045] Wired connection with other devices/networks may be by any appropriate standard or proprietary hardware and connectivity protocols. For example, system 200 may be configured for wired connection with other devices/communications networks by one or more of: Universal Serial Bus (USB); eSATA; Thunderbolt; Ethernet; HDMI. Other wired connections are possible.

[0046] Wireless connection with other devices/networks may similarly be by any appropriate standard or proprietary hardware and communications protocols. For example, system 200 may be configured for wireless connection with other devices/communications networks using one or more of: infrared; BlueTooth; WiFi; near field communications (NFC); Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), long term evolution (LTE), wideband code division multiple access (W-CDMA), code division multiple access (CDMA). Other wireless connections are possible.

[0047] Generally speaking, and depending on the particular system in question, devices to which system 200 connects - whether by wired or wireless means - include one or more input devices to allow data to be input into/received by system 200 for processing by the processing unit 202, and one or more output devices to allow data to be output by system 200. Example devices are described below, however, it will be appreciated that not all computer processing systems will include all mentioned devices, and that additional and alternative devices to those mentioned may well be used.

[0048] For example, system 200 may include or connect to one or more input devices by which information/data is input into (received by) system 200. Such input devices may include keyboards, mice, trackpads, microphones, accelerometers, proximity sensors, GPS devices and the like. System 200 may also include or connect to one or more output devices controlled by system 200 to output information. Such output devices may include devices such as a CRT displays, LCD displays, LED displays, plasma displays, touch screen displays, speakers, vibration modules, LEDs/other lights, and such like. System 200 may also include or connect to devices which may act as both input and output devices, for example, memory devices (hard drives, solid state drives, disk drives, compact flash cards, SD cards and the like) which system 200 can read data from and/or write data to, and touch screen displays which can both display (output) data and receive touch signals (input).

[0049] Where the system 200 is user device 130A or user device 130B, the system 200 includes or connects to a display 218 to output information. The display 218 may be a CRT display, LCD display, LED display, plasma display, or a touch screen display that can both display (output) data and receive touch signals (input).

[0050] System 200 also includes one or more communications interfaces 216 for communication with a network, such as network 102 of environment 100. Via the communications interface(s) 216, system 200 can communicate data to and receive data from networked devices, which may themselves be other computer processing systems.

[0051] System 200 may be any suitable computer processing system, for example, a server computer system, a desktop computer, a laptop computer, a netbook computer, a tablet computing device, a mobile/smart phone, a personal digital assistant, or an alternative computer processing system.

[0052] System 200 stores or has access to computer applications (also referred to as software or programs) - i.e. computer readable instructions and data which, when executed by the processing unit 202, configure system 200 to receive, process, and output data. Instructions and data can be stored on a non-transitory machine readable medium accessible to system 200. For example, instructions and data may be stored on non-transitory memory 210. Instructions and data may be transmitted to/received by system 200 via a data signal in a transmission channel enabled (for example) by a wired or wireless network connection over interface such as 212.

[0053] Applications accessible to system 200 will typically include an operating system application such as WindowsTM, macOSTM, iOSTM, AndroidTM, UnixTM, LinuxTM, or other operating system.

[0054] System 200 also stores or has access to applications which, when executed by the processing unit 202, configure system 200 to perform various computer-implemented processing operations described herein. For example, and referring to the networked environment of FIG. 1

IU

above, a user device such as 130A and/or 130B includes one or more client applications (e.g. 132 and/or 134) which configures the user device 130A and/or 130B to perform various operations described herein. Similarly, server system 110 includes a bank server application 112 which configures the server system 110 to perform various operations described herein.

Transaction processing

[0055] Figure 3 provides a flowchart illustrating operations involved in a transaction processing method 300. Generally speaking, transaction processing method 300 involves determining if additional authentication (e.g. 2FA) is required for a CNP transaction (and, if so, initiating an additional authentication process such as a 2FA process) as well as determining if additional services can be offered to the cardholder in relation to the CNP transaction before the CNP transaction is approved (and, if so, causing such services to be offered).

[0056] The operations of method 300 are described below as being executed by the issuing bank server application 112, however, one or more of these operations could be executed by alternative bank systems/applications. As an example, the risk determination performed at 304 may be executed by a specific risk determination system/module and the service determination performed at 306 may be executed by a specific service determination system/module.

[0057] At 302, the bank server application 112 receives an authentication request in relation to a CNP transaction. For example, the bank server application 112 may receive the authentication request from the 2FA application 142 of the third party server system 140 (which may itself generate the authentication request in response to receiving a transaction request from a merchant - e.g. from a merchant server application 122). The authentication request may be generated in accordance with a 2FA protocol, for example the 3-D Secure protocol (or an alternative 2FA protocols). The authentication request is triggered in response to a cardholder attempting to purchase goods/services from a merchant's ecommerce site, for example when a cardholder attempts to purchase goods/services from the merchant (e.g. using merchant client application 132 on user device 130A) by browsing the merchant's ecommerce site, selecting goods/services, and entering their transaction card details. The authentication request may include the following data: • Transaction data including data relating to the transaction amount, a transaction currency, and the type of transaction; • Transaction card data including data relating to the cardholder's name on the transaction card, the expiry data of the transaction card, and the card verification value (CVV) of the transaction card; and

• Merchant data including data relating to a merchant identifier (e.g. the merchant's name or unique identification code), merchant location codes (e.g. to determine the merchant's country and/or region), merchant category codes (e.g. to determine the goods and/or services the merchant provide), what currency the cardholder is being billed in (e.g. the merchant's currency or the issuing bank's currency), if the cardholder has had previous transactions with the merchant (i.e. a return shopper), and/or other merchant details.

[00581 At 304, the bank server application 112 calculates a risk associated with the transaction - e.g. a risk score indicating the likelihood that the transaction is fraudulent. This calculation may be based on various data, for example, the merchant data received with the authentication request, the issuing bank's own data, and/or data from any other source. By way of simple example, factors that contribute to calculating the risk of fraud may include unusual or large purchases, first time purchases with a particular merchant, purchases originating from a country/geographic region in which the cardholder does not reside, and/or that the country/merchant in question has been flagged as higher risk.

[0059] At 306, the bank server application 112 determines if there are any additional services that can be offered to the cardholder in relation to the CNP transaction before approving the CNP transaction. The services that can be offered may be based on the cardholder's account data, merchant data received at 302, and/or other data available to the bank server application 112. As discussed in detail below, the processing performed to identify whether a given service is relevant to the CNP transaction depends on the service in question. Generally speaking, however, the bank server application 112 will determine if any additional services can be offered based on one or more of: data included in the authentication request, data associated with the cardholder whose transaction card is being used for the transaction, data associated with the merchant involved in the transaction (either as included in the authentication request or obtained from other sources), and/or any other relevant data.

[00601 As an example, the bank server application 112 may determine any additional services to offer the cardholder based on one or more of the following: • Pre-validation check- this may involve the bank server application 112 determining if the cardholder has funds available for the CNP transaction in question, if any details (e.g. phone number or email address) of the cardholder has been recently updated which may indicate suspicious behaviour, and/or any other data relating the cardholder.

• Active cardholder controls - this may involve the bank server application 112 determining any active controls in place for the cardholder (self or bank imposed), for example, locked cards, blocked cards, and exclusions for particular transaction types (e.g. gambling). • Cardholder offers relating to the CNP transaction - this may involve the bank server application 112 offering product protection for the CNP transaction in question (discussed below), and/or merchant reward offers. • Merchant reliability data - this may involve the bank server application 112 determining reliability of the merchant in question (i.e. the likelihood that the merchant is fraudulent) based on any complaints associated with the merchant and/or any other data relating to the merchant. • Transaction level data - this may involve the bank server application 112 determining if there are any services and/or security concerns to offer/raise in relation to the CNP transaction in question (e.g. the bank server application 112 may determine that the merchant is part of an offers program with the issuing bank and may present any offers from the offers program to the cardholder in response to determining that the CNP transaction in question is in relation to this particular merchant). • Merchant level information, for example, merchant category codes, merchant location codes, the transaction currency code to determine the currency with which the CNP transaction in question is proceeding, and/or any other data relating to the merchant.

[00611 It will be appreciated that the above list is not exhaustive and that other information available to the issuing bank may be used to determine which services to offer a cardholder. In determining whether a particular service can be offered to the cardholder the bank server application 112 may - though need not - take the transaction risk calculated at 304 into account. By way of example, determining whether the unlock card service as described below can/should be offered does not (at least in the described embodiment) involve consideration of any transaction risk. Conversely, the bank server application 112 may (in certain implementations) be configured take the transaction risk calculated at 304 into account when determining whether the product protection service (also described below) can/should be offered.

[0062] By way of example, one of the services discussed below is a card unlock service. To determine whether this service should be offered, the bank server application 112 will check to see if the transaction card relevant to the transaction in question is locked. The manner in which this query is made will depend on the manner in which the issuing bank stores cardholder data.

I.:

[00631 The bank server application 112 may use the transaction card number of the transaction card in question to query a card lock data structure such as the following to determine if the transaction card is locked:

Transaction card No. Cardholder lock active?

[0064] It will be recognised that the above table is by way of illustration only. A typical bank or financial institution will store a large amount of data in respect of its customers, often across multiple tables linked by appropriate identifiers (e.g. in a relational database).

[0065] At 308, the bank server application 112 determines if there are one or more services to offer to the cardholder in relation to the CNP transaction in question. If so, processing proceeds to step 310. If not, processing proceeds to step 322.

[0066] At 310, one or more services have been identified. In this case, the bank server application 112 prioritises each of the services determined at 308 to determine which, if any, of those services to offer to the cardholder. If only one service has been identified (or fewer services than a defined threshold service number), service prioritisation at 310 may be omitted. If more than one service (or more than the defined threshold service number) is/are identified, service prioritisation is performed at 310, as it may not be feasible or desirable to offer all identified services to the cardholder. In this case, the services that have been identified are prioritised in order to determine a subset of one or more services that are actually to be offered to the cardholder.

[0067] As an example, the bank server application 112 may prioritise services that require a response from the cardholder in order for the CNP transaction to proceed. Such services are discussed below and are referred to as response required services. The bank server application 112 may also prioritise services based on a ranking system developed by the issuing bank. The bank server application 112 may only prioritise a predetermined number of services so as to allow the cardholder to consider and/or reply to each offered service with the transaction time limit (discussed below).

[00681 At 312, the bank server application 112 performs processing to cause each of the services prioritised at 310 to be offered. The processing performed to offer a given service depends on the service itself and is discussed below. In the present embodiments, the processing involved in offering a particular service is performed by the services application 116. In this case, causing a service to be offered involves notifying the services application 116, for example, via an API call, remote procedure call, or other message to the relevant application, including any data required by that application to offer the service (e.g. a cardholder transaction card number, transaction details, and/or other relevant data relating to the CNP transaction, merchant, cardholder, or other details).

[0069] The services offered to the cardholder may be classified as a response required service, a response optional service, or an information only service. Response required services are services that request and require a response from the cardholder if the CNP transaction is to be approved (noting that transaction approval may also require further authentication such as 2FA, as determined at 322). An example of a response required service is the unlock card service (discussed in detail below). Response optional services are services that request a response from the cardholder but a response is not required for the CNP transaction to be approved. An example of a response optional service may be a payment options service (discussed in detail below). Information only services are services that provide information to the cardholder in relation to the CNP transaction and that do not request or require a response from the cardholder for the CNP transaction to be approved. An example of an information only service may be a FX notification service (discussed below).

[0070] At 314, the bank server application 112 determines if any of the services offered are response required services or response optional services. If so, processing proceeds to step 316. If not, processing proceeds to step 322.

[0071] At 316, the bank server application 112 awaits a response from the services application 116 for each of the response required and response optional services that have been offered to the cardholder. For a given service that has been offered (and that requires or allows a response) the service response received from the services application 116 may be a "proceed with transaction" response or a "decline transaction" response". In the present embodiment the bank server application 112 will only wait for service responses for a predetermined service response timeout period. The service timeout period may be based on a transaction time limit (e.g. 30 seconds) i.e. so that the transaction will not time out with the server application 112 still awaiting one or more service responses.

[0072] At 318, the bank server application 112 determines, based on service responses received or not received, if the CNP transaction in question should proceed or if the transaction in question should be declined. Specifically, in the present embodiment: in response to determining that a service response in respect of any response required service has not been received within the service response timeout period , the bank server application 112 proceeds to step 320. In response to determining that any service response received from the services application 116 is a "decline transaction" response, the bank server application 112 proceeds to step 320. Otherwise, the bank server application 112 proceeds to step 322 (in this case any non-received responses are for response optional services and all responses that have been received are "proceed with transaction" service responses).

[0073] To illustrate this, consider the unlock card service discussed below which is an example of a response required service. This service may involve identifying that the relevant transaction card that is to be used for the CNP transaction is currently locked for transactions and providing the cardholder with an option to unlock the transaction card for the CNP transaction in question. If the cardholder responds by unlocking the transaction card, the services application 116 generates and communicates a "proceed with transaction" response to the bank server application 112. In this case (and if this was the only service offered), processing would proceed to 322 to determine if 2FA is required. If, however, the cardholder responds by declining to unlock the transaction card, the services application 116 generates and communicates a "decline transaction" response to the bank server application 112. In this case the transaction is declined at 320 (there being no point proceeding with the CNP transaction as it will not be able to be processed even if the cardholder successfully completes a 2FA process). As will be appreciated, this provides both network communication and data processing resource benefits, as a 2FA process that may otherwise have been performed (involving, for example, generating a 2FA code, communicating this to the cardholder, the cardholder providing the code to the merchant, and the merchant confirming the code) is avoided.

[0074] At 320, the bank server application 112 declines the CNP transaction. For example, declining the CNP transaction may involve the bank server application 112 communicating a transaction declined notification to the 2FA application 142 of the third party server system 140, which in turn may communicate a transaction declined notification to the merchant.

[0075] In process 300, the transaction may be declined at 320 without even determining if 2FA is required and/or completing a 2FA process. In other embodiments, however, the requirement for 2FA may be determined prior to (or in parallel with) determining/offering services. In such embodiments the CNP transaction will be declined at 320 regardless of whether or not it has been determined that 2FA is required.

[0076] The bank server application 112 may generate and communicate a transaction declined notification to the cardholder notifying them that the CNP transaction in question has been declined and why it has been declined (e.g. due to the transaction card being locked). The transaction declined notification may be communicated to the cardholder via the bank client application 134 on the cardholder's user device 130B (e.g. as a pop-up notification or overlay message), as an SMS sent to the cardholder's user device 130B, an email sent to the cardholder's nominated email address, or any other communication means.

[0077] At 322, either no services have been offered to the cardholder or none of the services offered have led to the transaction being declined at 320. In this case the bank server application 112 determines if 2FA is required for the CNP transaction in question. In the present embodiment this determination is based on the transaction risk calculated at 304. If 2FA is required, the bank server application 112 proceeds to step 324. If not, the bank server application 112 proceeds to step 326.

[00781 At 324, the bank server application 112 initiates 2FA for the CNP transaction in question. The 2FA may utilise any suitable 2FA protocol known in the art, for example the 3-D secure protocol.

[0079] In an example, the bank server application 112 generates and communicates a one time password to the cardholder. The one-time password may be communicated to the cardholder via the bank client application 134 on the cardholder's user device 130B as a notification (e.g. pop-up notification), as an SMS to the cardholder's user device 130B, an email to the cardholder's nominated email address, or any other suitable communication means. The cardholder then enters the one-time password via the merchant's ecommerce site to authenticate the CNP transaction. Subsequently, the CNP transaction is completed using any suitable methods known in the art. This may involve, for example, communicating a transaction approval/rejection to the 2FA application 142 of the third party server system 140 which can then communicate with the merchant server system 120/application 122 accordingly.

[0080] At 326, the bank server application 112 has determined that 2FA is not required. In this case, the bank server application 112 completes the CNP transaction without 2FA using any suitable methods known in the art. For example, completing the CNP transaction may involve the bank server application 112 communicating a transaction approved notification to the 2FA application 142 of the third party server system 140, which in turn may communicate a transaction approved notification to the merchant.

/ Example services

[0081] Method 300 as described above involves identifying services that could be offered to a cardholder (at 306), prioritising services that have been identified (at 310), and offering services (at 312). The processing performed at each of these steps depends on the different types of services that the issuing bank server system 110 is configured to provide.

[0082] At 312, the bank server application 112 causes a particular service to be offered. As described above, in the present embodiments, this involve an API call, RPC, or other message to a services application such as 116 that is responsible for offering the service in question.

[00831 This section describes example services that may be provided by the issuing bank server system 110. It will be appreciated, however, that fewer, additional, and/or alternative services may be offered. The services described in this section are described as being performed by the services application 116. As noted above, however, a given service could be performed by any appropriate application or system, and/or multiple different applications/systems may operate to provide different services.

Unlock card service

[0084] Bank server system 110 may provide cardholders with the ability to place a customer lock on a transaction card - e.g. so that any (or certain, as defined by various lock parameters) transactions received are declined. In these cases, a CNP transaction may be declined because a cardholder's transaction card is locked. As the customer-lock is a separate mechanism to 2FA mechanisms such as 3DS, it is possible for a cardholder to initiate a transaction, successfully complete a 3DS or other 2FA process, yet still have the transaction declined due to forgetting to remove the customer-lock that had previously been placed on the transaction card in question.

[0085] Accordingly, the present service provides a mechanism that alerts a cardholder whose transaction card is being used in a transaction that the transaction card is locked and enables the cardholder to release the lock before the CNP transaction is approved. This avoids the CNP transaction being declined due to an active lock at a later stage - for example after a cardholder has progressed through a 2FA process. It can also serve to identify instances of fraudulent (or likely fraudulent) behaviour, in that if a cardholder that has not initiated a transaction receives an offer to unlock their transaction card for such a transaction they will likely realise something is amiss and escalate this (either as part of the unlock card service or an alternative mechanism).

[00861 In the present example, the unlock card service is initiated by the bank server application 112 determining (at 306) that the transaction card that the authentication request received at 302 relates to has an active customer-lock thereon. This involves querying relevant data (either directly or via another issuing bank service/application) using the cardholder's transaction card details. If the transaction card has an active customer-lock, the bank service application 112 determines that the unlock card service can be offered. If the unlock card service is actually to be offered, at 312 the bank service application 112 generates and communicates an unlock card service API call, RPC, or alternative message to the services application 116. The unlock card service call/message will include data allowing the services application 116 to identify the relevant transaction card. The unlock card call/message may also include data in respect of the transaction amount and merchant.

[0087] Turning to Figure 4, operations performed by the services application 116 in an card unlock process 400 will be described.

[00881 At 402, the unlock card service is triggered - for example by the services application 116 receiving an unlock card service API call, RPC, or alternative message from the bank server application 112.

[00891 At 404, the services application 116 generates a card locked notification and causes this to be presented to the cardholder.

[0090] In the present example, the services application 116 causes the card locked notification to be presented to the cardholder on user device 130B via the bank client application 134), for example as a popup/overlay or other user interface mechanism.

[0091] Figure 5 provides an example card locked notification 500 displayed on a display 218 of a user device 130B. In this example, card locked notification 500 includes information 502 concerning the transaction (e.g. a merchant name and transaction amount, received by the services application 116 in the unlock card call/message), an unlock card control 504, an unlock card for this transaction control 506, a do not unlock card control 508, and a fraud alert control 510. In this example, controls 504, 506, 508 and 510 are user interface controls which can be activated via appropriate user input (e.g. contacting the control where the display 218 is a touch screen display, clicking on the control via a mouse/cursor, or an alternative input). Additional controls may be provided to allow a user to perform other unlock operations, for example unlocking the transaction card for a defined time window, a defined transaction amount, or other unlock operations. Fewer

I I1

controls may also be provided - for example, the card locked notification may include a single 'unlock card for this transaction' control such as 506.

[0092] In alternative embodiments, the services application 116 may alternatively (or additionally) cause the card locked notification to be presented to the cardholder via an email, instant message, SMS message, or alternative mechanism. In this case, controls such as 504, 506, 508 and/or 510 may be presented as links (such as URLs) or other controls which can be activated by the cardholder.

[00931 At 406, the services application 116 receives a card locked notification response to the card locked notification. Services application 116 may be configured to terminate process 400 if no response to the notification is received within a predetermined time period. In this case services application 116 does not generate/communicate a service response to the bank service system 110 which itself will time out with respect to the service (at 316). In the present embodiment, the card locked notification response may be an unlock card response, an unlock card for transaction response, a do not unlock card response, or a fraud alert response. Alternative responses are possible.

[0094] If the services application 116 receives an unlock card response at 406 processing proceeds to 410. An unlock card response is generated by a user device 130B when a user activates an unlock card control presented in the card locked notification (e.g. control 504). At 410, the services application 116 unlocks the relevant transaction card (or causes the relevant transaction card to be unlocked) before generating a 'proceed with transaction' service response and communicating this to the bank server application 112 at 412.

[0095] If the services application 116 receives an unlock card for this transaction response at 406 processing proceeds to 414. An unlock card for this transaction response is generated by a user device 130B when a user activates an unlock card for this transaction control presented in the card locked notification (e.g. control 506). At 414, the services application 116 unlocks the relevant transaction card (or causes the relevant transaction card to be unlocked) for the transaction before generating a 'proceed with transaction' service response and communicating this to the bank server application 112 at 416.

[0096] Services application 116 may unlock a transaction card for a specific transaction in various ways. In the present example, after unlocking the transaction card at 414 the services application 116 monitors for the transaction to be completed (or declined) at 418. For example, the services application 116 may receive a "transaction completed" message or a "transaction

4U

declined" message from the bank server application 112 indicating that the CNP transaction in question has been completed or declined. On receive of a transaction completed or transaction declined message (or on expiry of a time-out period), services application 116 then re-locks the transaction card at 420.

[0097] If the services application 116 receives a do not unlock card for this transaction response at 406 processing proceeds to 424. A do not unlock card response is generated by a user device 130B when a user activates a do not unlock card control presented in the card locked notification (e.g. control 508). At 424, the services application 116 generates a 'decline transaction' service response and communicates this to the bank server application 112. This is done without unlocking the transaction card.

[0098] If the services application 116 receives a fraud alert response at 406 processing proceeds to 422. A fraud alert response is generated by a user device 130B when a user activates a fraud alert control presented in the card locked notification (e.g. control 510). At 422, the services application initiates a fraud process. This may involve various operations. For example, the services application 116 may generate and communicate a fraud notification to the bank server application 112 (or a dedicated fraud application running on the same or different physical systems) indicating that a fraudulent transaction was attempted using the cardholder's transaction card details. The fraud notification may include data provided with the authentication request received at 302 and any other data relating to the CNP transaction - e.g. the transaction card details, transaction card details, and/or other data. The bank server application 112 (or dedicated fraud application) may record and/or use the fraud notification to investigate the fraudulent transaction. The services application may also (or alternatively) cause a further lock (that the cardholder cannot remove) on the transaction card, cause transaction card(s) associated with the transaction to be cancelled, and/or perform other operations. Following initiation of a fraud process at 424, at 426 the services application 116 generates a 'decline transaction' service response and communicates this to the bank server application 112.

Foreign exchange (FX) notification service

[0099] A common scenario for cardholders when shopping with a merchant that has a merchant currency that is different to the issuing bank currency (or a billing currency associated with the cardholder transaction card being used for the transaction) is for the cardholder to be presented with a dynamic currency conversion (DCC) offer. Such an offer involves the merchant offering to bill the transaction in the issuing bank currency. For example, if the merchant is a US

4I

merchant and the issuing bank currency is AU$, a DCC offer would involve the merchant offering to bill the cardholder in AU$. For DCC offers the conversion from the merchant currency to the issuing bank currency is performed using a FX conversion rate selected by the DCC company (and may include additional DCC fees).

[0100] This is in contrast to the scenario where a cardholder completes the transaction in the merchant's currency and the FX conversion is handled by the issuing bank (in which case the issuing bank's conversion rates are used, along with any issuing bank transaction fees).

[0101] Opting in to the DCC offer may be an unfavourable option for the cardholder because the DCC FX conversion (and any fees) may result in a higher cost than the issuing bank FX conversion (and any fees).

[0102] In order to provide a cardholder with better visibility, a service offered by the issuing bank may be a FX notification service. The FX notification service may involve, for example, notifying the cardholder of the transaction cost (and/or potential savings) if the cardholder proceeds with the transaction in the merchant's currency (allowing the issuing bank to handle the foreign exchange) rather than proceeding with the transaction in the issuing bank currency (and allowing the merchant (or DCC provider) to handle the foreign exchange).

[01031 The FX notification service may be an information only service, which does not require a response from the cardholder.

[0104] In the present example, the FX notification account service is initiated by the bank server application 112 determining (at 306), based on data included in or associated with the authentication request, that the merchant is based overseas/has a normal billing currency other than the issuing bank currency and that the cardholder is going to be billed in the issuing bank currency. If the FX notification service is actually to be offered, at 312 the bank service application 112 generates and communicates a FX notification service API call, RPC, or alternative message to the services application 116. The FX notification service call/message will include data such as the merchant currency, the transaction amount in the merchant currency, and the transaction amount in the issuing bank currency following DCC conversion.

[0105] Turning to Figure 6, operations performed by the services application 116 in a FX notification process 600 will be described.

zz

[01061 At 602, the FX notification service is triggered - for example by the services application 116 receiving a FX notification service API call, RPC, or alternative message from the bank server application 112.

[0107] At 604, the services application 116 calculates an issuing bank conversion amount for the transaction - i.e. the amount the CNP transaction will cost the cardholder if the cardholder proceeds with the transaction in the merchant's currency (allowing the issuing bank to handle the foreign exchange). To do so the services application 116 may access foreign exchange data including exchange rates and/or foreign exchange transaction fees and calculate an issuing bank conversion.

[01081 At 606, the services application 116 causes a FX conversion notification to be presented to the cardholder.

[0109] In the present example, the services application 116 causes the FX conversion notification to be presented to the cardholder on user device 130B via the bank client application 134), for example as a popup/overlay or other user interface mechanism. In alternative embodiments, the services application 116 may alternatively (or additionally) cause the FX conversion notification to be presented to the cardholder via an email, instant message, SMS message, or alternative mechanism.

[0110] The FX conversion notification indicates to the cardholder indicate how much the CNP transaction will cost if the cardholder decides to be billed in the merchant's currency (and have currency exchange handled by the cardholder's bank), as determined at 604. The FX conversion notification may also indicate how much the CNP transaction will cost if the cardholder decides to be billed in the issuing bank currency (and have currency exchange handled by the merchant/DCC provider). The FX conversion notification may also include a FX difference - for example how much the cardholder will save (or how much additional the transaction will cost) by completing the transaction in the issuing bank currency. The difference can be calculated by subtracting the issuing bank conversion amount calculated at 604 from the amount the transaction would cost if proceeding via merchant/DCC conversion to the issuing bank currency. Based on this information, the cardholder may elect to cancel the CNP transaction and initiate the CNP transaction again with the currency option that is most favourable to the cardholder.

[0111] Figure 7 provides an example FX notification 700 displayed on a display 218 of a user device 130B. In this example, FX notification 700 includes information 702 concerning the transaction (e.g. a merchant name), information 704 concerning how much the CNP transaction will cost them if they decide to be billed in the merchant's currency (and have currency exchange handled by the cardholder's bank), information 706 concerning how much the CNP transaction will cost them if they decide to be billed in the issuing bank currency (and have currency exchange handled by the merchant/DCC provider), and difference information 708 (indicating how much the cardholder saves/spends by choosing to proceed in the merchant's currency vs the issuing bank currency).

Product protection service

[0112] By way of further example, a service offered by the issuing bank may be a product protection service. The product protection service may, for example, involve the issuing bank offering insurance for the goods/services the cardholder is going to purchase through the CNP transaction. The product protection service may, for example, offer insurance for failed delivery, damage to the goods/services, price protection, and/or other protections.

[01131 This service may be a response optional service as it is the cardholder's choice as to whether or not they would like to purchase insurance for the CNP transaction in question. In an example, if the cardholder does not provide a response to the product protection service, the services application 116 determines that the cardholder does not want to purchase insurance for the goods/services. In this case, however, as the service is a response optional service the transaction may nonetheless proceed.

[0114] In the present example, the product protection service is initiated by the bank server application 112 determining (at 306) that the cardholder is eligible for this service based on the type of transaction card the cardholder has and/or that product protection may be warranted based on the transaction type, transaction amount, merchant reliability data, and/or any other data available to the bank server application 112. If the product protection service is actually to be offered, at 312 the bank service application 112 generates and communicates a product protection service API call, RPC, or alternative message to the services application 116.

[0115] In response to receiving the product protection service call/message, the services application 116 performs processing to generate and present a product protection offer to the cardholder. The product protection office notification may be communicated to the cardholder via the bank client application 134 on the cardholder's user device 130B (e.g. as a pop-up notification or overlay message), as an SMS sent to the cardholder's user device 130B, an email sent to the cardholder's nominated email address, or any other communication means.

Z1+

[01161 In an example, the product protection offer may include a "purchase product protection" control and a "no" control.

[0117] In response to the cardholder selecting the "purchase product protection" control, the services application 116 may direct the cardholder (e.g. via bank client application 134 on user device 130B) to an insurance webpage through which the cardholder may purchase insurance for the goods/services relating to the CNP transaction in question. In response to detecting that the cardholder has selected the "purchase product protection" control or that the cardholder has purchased product protection after selecting the "purchase product protection" control, the services application 116 may generate and communicate a "proceed with transaction" response to the bank server application 112.

[0118] In response to the cardholder selecting the "no" control, the services application 116 may generate and communicate a "proceed with transaction" response to the bank server application 112.

Payment options service

[0119] By way of further example, a service offered by the issuing bank may be a payment options service. The payment options service may involve, for example, the issuing bank offering the cardholder the option of a payment plan for paying off the transaction amount of the CNP transaction in instalments. This service may be provided as a response required service or a response optional service.

[0120] In the present example, the payment options service is initiated by the bank server application 112 determining (at 306) that the cardholder is eligible for this service based on the type of transaction card the cardholder has and/or the likelihood of the cardholder taking advantage of this service. The likelihood of the cardholder taking advantage of this service may take into account whether the cardholder has previously taken advantage of this service and/or other data available to the bank server application 112. If the payment options service is actually to be offered, at 312 the bank service application 112 generates and communicates a payment options service API call, RPC, or alternative message to the services application 116.

[0121] In response to receiving the payment options service API call, RPC, or alternative message, the services application 116 performs processing to generate and present a payment options offer to the cardholder. The payment option offer may be communicated to the cardholder via the bank client application 134 on the cardholder's user device 130B (e.g. as a pop-up notification or overlay message), as an SMS sent to the cardholder's user device 130B, an email sent to the cardholder's nominated email address, or any other communication means.

[0122] In an example, the payment option offer may include a "pay normally" control and a "payment options" control.

[0123] In response to the cardholder selecting the "pay normally" control, the services application 116 determines that the cardholder would like to complete the transaction using the transaction card details received with the authentication request at 302 and generates and communicates a "proceed with transaction" service response to the bank server application 112.

[0124] In response to the cardholder selecting the "payment options" control, the services application 116 may direct the cardholder (e.g. via bank client application 134 on user device 130B) to a payment option webpage through which the cardholder may select a payment option for paying off the CNP transaction in question. In response to detecting that the cardholder has selected the "payment options" control or that the cardholder has selected a payment option after selecting the "purchase product protection" control, the services application 116 may generate and communicate a "proceed with transaction" response to the bank server application 112.

[0125] If this service is a response required service, the cardholder will have to select either the "pay using card" or the "payment options" control in order for the CNP transaction to proceed. If no response is received from the cardholder to the payment options notification, the bank server application 112 will decline the CNP transaction (i.e. proceed to step 320).

[0126] If this service is a response optional service, the cardholder is not required to select either of the "pay using card" or the "payment options" controls for the CNP transaction to proceed. If a response is not received to the payment options control, the bank server application 112 may complete the CNP transaction using the transaction card details received with the authentication request at 302.

Use alternative funds service

[0127] By way of further example, a service offered by the issuing bank may be a use alternative funds service. If the account associated with the transaction card being used for the CNP transaction does not have sufficient funds to pay for the CNP transaction, the CNP transaction will be declined because of insufficient funds. However, the user may have another account with the issuing bank that could cover the shortfall in funds.

zo

[0128] Accordingly, the use alternative funds service provides a mechanism that alerts the cardholder that the account associated with the transaction card they are using for the CNP transaction has insufficient funds and enables the cardholder to transfer funds from another account of the cardholder to cover the shortfall in funds. This avoids the CNP transaction being declined because of insufficient funds. This service may be provided as a response required service.

[0129] In the present example, the use alternative funds service is initiated by the issuing bank server application 112 determining (at 306) that the account associated with transaction card being used for the CNP transaction has insufficient funds and that the cardholder has another account with the issuing bank that could cover the shortfall in funds. This involves querying relevant data (either directly or via another issuing bank service/application) using the cardholder's transaction card details. If the use alternative funds service is actually to be offered, the bank service application 112 generates and communicates a use alternative funds service API call, RPC, or alternative message to the service application 116.

[01301 In response to receiving the use alternative funds service API call, RPC, or alternative message, the services application 116 performs processing to generate and present a use alternative funds offer to the cardholder. The use alternative funds offer may be communicated to the cardholder via the bank client application 134 on the cardholder's user device 130B (e.g. as a pop up notification or overlay message), as an SMS sent to the cardholder's user device 130B, an email sent to the cardholder's nominated email address, or any other communication means.

[01311 In an example, the use alternative funds offer notifies the cardholder that the account associated with transaction card being used for the CNP transaction has insufficient funds and that they have another account that could cover the shortfall in funds. The use alternative funds offer also includes a "use alternative funds" control and a "do not use alternative funds" control.

[0132] In response to the cardholder selecting the "use alternative funds" control, the bank service application 116 causes funds to transfer from the cardholder's other account to the account associated with the transaction card being used for the CNP transaction and generates a "proceed with transaction" service response and communicating this to the bank server application 112.

[01331 In response to the cardholder selecting the "do not use alternative funds" control, or not receiving any response to the use alternative funds offer within a defined timeout period, the bank service application 116 generates and communicates a "decline transaction" service response

/ to the bank server application 112, which will decline the CNP transaction (i.e. proceed to step 320).

[0134] 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 (17)

1. A computer implemented method comprising: receiving an authentication request in relation to a card not present transaction, the authentication request being a request for authentication of a transaction with a merchant using a transaction card associated with a cardholder, the authentication request including transaction card data relating to the transaction card; determining, using the transaction card data, if the transaction card is locked; in response to determining that the transaction card is locked, causing a card locked notification to be presented at an electronic device of the cardholder ; receiving a card locked notification response from the electronic device; and in response to the card locked notification response being an unlock card response: unlocking the transaction card; and completing the authentication request.

2. The computer implemented method of claim 1, further comprising, in response to the card locked notification response being a do not unlock card response: foregoing unlocking the transaction card; and declining the card not present transaction without completing the authentication request.

3. The computer implemented method of claim 1 or 2, further comprising, in response to the card locked notification response being an unlock card for transaction response: unlocking the transaction card; completing the authentication request; determining that the card not present transaction has been completed or declined; and in response to determining that the card not present transaction has been completed or declined, locking the transaction card.

4. The computer implemented method of any one of the preceding claims, further comprising, in response to the card locked notification response being a fraud alert response: foregoing unlocking the transaction card; and declining the card not present transaction without completing the authentication request.

5. The computer implemented method of claim 4, further comprising initiating a fraud process in response to the fraud alert response.

6. The computer implemented method of any one of the preceding claims, wherein completing the authentication request comprises: determining if a two factor authentication is required for the card not present transaction; in response to determining that the two factor authentication is required, initiating the two factor authentication.

7. The computer implemented method of claim 6, wherein, in response to determining that the two factor authentication is not required for the card not present transaction, foregoing initiating the two factor authentication.

8. The computer implemented method of any one of the preceding claims, wherein the authentication request is generated in accordance with a two factor authentication protocol.

9. The computer implemented method of claim 8, wherein the two factor authentication protocol is a 3D secure protocol.

10. The computer implemented method of any one of the preceding claims, wherein causing the card locked notification to be presented at the electronic device of the cardholder comprises: causing the card locked notification to be presented by a bank client application on the electronic device of the cardholder.

11. The computer implemented method of claim 10, wherein the bank client application is a dedicated application installed on the electronic device of the cardholder.

12. The computer implemented method of any one of claims 1 to 9, wherein causing the card locked notification to be presented at the electronic device of the cardholder comprises: causing the card locked notification to be presented to the cardholder via an email.

13. The computer implemented method of any one of claims 1 to 9, wherein causing the card locked notification to be presented at the electronic device of the cardholder comprises: causing the card locked notification to be presented to the cardholder via an SMS message.

14. The computer implemented method of any one of the preceding claims, wherein the electronic device is a mobile telephone.

15. A computer implemented method comprising: receiving an authentication request in relation to a card not present transaction, the authentication request being a request for authentication of a transaction with a merchant using a transaction card associated with a cardholder, the authentication request including transaction data relating to the card not present transaction; determining one or more services to offer to the cardholder using the transaction data; causing offers in respect of the one or more services to be presented at an electronic device ofthe cardholder.

16. A computer processing system comprising: a processing unit; a communication interface; and non-transitory computer-readable storage medium storing instructions, which when executed by the processing unit, cause the processing unit to perform a method according to any one of claims I to 15.

17. A non-transitory storage medium storing instructions executable by a processing unit to cause the processing unit to perform a method according to any one of claims 1 to 15.