U.S. patent application number 11/643939 was filed with the patent office on 2007-08-23 for transaction processing.
This patent application is currently assigned to SNAPCOUNT LIMITED. Invention is credited to Patrick Brosnan, Conor Clarke, Kieron Guilfoyle, Stephen Kavanagh.
Application Number | 20070198411 11/643939 |
Document ID | / |
Family ID | 11042804 |
Filed Date | 2007-08-23 |
United States Patent
Application |
20070198411 |
Kind Code |
A1 |
Kavanagh; Stephen ; et
al. |
August 23, 2007 |
Transaction processing
Abstract
A transaction processing system for the real time authorisation
of payment transactions, The system comprises a verification system
(4) connected to an issuer card management system (3). A cardholder
can access the system via an interface (2) which can be for example
the Internet, a wireless device, telephone, or a branch visit. The
interface allows the cardholder to input rules governing how their
credit card transactions are to be authorised. When the cardholder
initiates a purchase transaction with their credit card, an
authorisation request is passed from the card network to the
verification system which executes the rules created by the
cardholder in order to approve or deny the transaction.
Inventors: |
Kavanagh; Stephen; (County
Dublin, IE) ; Clarke; Conor; (County Dublin, IE)
; Guilfoyle; Kieron; (County Dublin, IE) ;
Brosnan; Patrick; (County Dublin, IE) |
Correspondence
Address: |
JACOBSON HOLMAN PLLC
400 SEVENTH STREET N.W.
SUITE 600
WASHINGTON
DC
20004
US
|
Assignee: |
SNAPCOUNT LIMITED
|
Family ID: |
11042804 |
Appl. No.: |
11/643939 |
Filed: |
December 22, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10735642 |
Dec 16, 2003 |
|
|
|
11643939 |
Dec 22, 2006 |
|
|
|
PCT/IE02/00093 |
Jun 27, 2002 |
|
|
|
10735642 |
Dec 16, 2003 |
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06Q 20/08 20130101;
G06Q 20/1085 20130101; G07F 7/122 20130101; G06Q 20/305 20130101;
G06Q 20/405 20130101; G07F 7/08 20130101; G06Q 20/22 20130101; G06F
16/21 20190101; G06Q 20/407 20130101; G06Q 20/40 20130101; G06Q
40/02 20130101; G06Q 20/4037 20130101; G06Q 20/24 20130101; G06Q
20/354 20130101; G06Q 20/32 20130101; G06Q 20/403 20130101; G06Q
20/4014 20130101; G06Q 20/10 20130101; G06Q 20/04 20130101; G06Q
20/34 20130101; G06Q 20/102 20130101; G06K 19/00 20130101; G06Q
20/108 20130101 |
Class at
Publication: |
705/044 |
International
Class: |
G06Q 40/00 20060101
G06Q040/00 |
Foreign Application Data
Date |
Code |
Application Number |
Jun 27, 2001 |
IE |
2001/0594 |
Claims
1. A transaction processing system comprising an interface for
receiving authorisation requests, an interface for transmitting
authorisation outputs, and a processing means comprising means for
determining from authorisation request data if the system output
should be positive or negative, characterised in that the
processing means comprises: a setup means comprising means for
storing transaction conditions associated with particular
customers, and authorisation means for dynamically retrieving a
transaction condition associated with the customer of each
authorisation request on a per-transaction basis and for applying
said conditions to the authorisation request wherein the setup
means comprises an interface comprising means for allowing each
customer to define said conditions; wherein at least some of the
conditions are in the form of program code rules; wherein the setup
means comprises means for maintaining a rule database; wherein the
authorisation means comprises means for automatically transmitting
a notification to a customer under control of the conditions;
wherein the authorisation request interface comprises a network
interface for interfacing with a card payment network; wherein the
authorisation request interface comprises a network interface for
interfacing with an issuer front end system; wherein the output
interface further comprises a card management system interface for
interfacing with an issuer card management system; and wherein the
setup means comprises means for controlling customer activation of
a card.
2. The transaction processing system as claimed in claim 1, wherein
said interface comprises a Web server.
3. The transaction processing system as claimed in claim 1, wherein
the setup means comprises means for storing predefined template
conditions, and for allowing a customer to select predefined
template conditions for his or her card.
4. The transaction processing system as claimed in claim 3, wherein
the setup means comprises a fraud manager interface comprising
means for allowing a fraud manager with access control to define
said template conditions.
5. The transaction processing system as claimed in claim 3 wherein
the predefined template condition comprises specific placeholders
for conditions, values and logical operators.
6. The transaction processing system as claimed in claim 3 wherein
the setup means comprises input means for allowing a customer to
input customer specified parameters to the predefined template
conditions.
7. The transaction processing system as claimed in claim 3, wherein
each template comprises an associated action which is the action to
be taken if, upon evaluation, the template condition evaluates to
"true".
8. The transaction processing system as claimed in claim 1, wherein
the rule database comprises means for storing rules in a format
which is indexed on a particular customer or customer card
number.
9. The transaction processing system as claimed in claim 8, wherein
said rules comprise system, product and customer rules.
10. The transaction processing system as claimed in claim 1,
wherein said rules are stored in a format which does not require
parsing of logical string-based expressions for processing.
11. The transaction processing system as claimed in claim 1,
wherein the authorisation means comprises means for receiving
confirmation of authorisation from a customer in response to a
notification.
12. The transaction processing system as claimed in claim 1,
wherein the authorisation means comprises means for successively
applying system-level, card product-level, and the customer
conditions upon receipt of an authorisation request.
13. The transaction processing system as claimed claim 1, wherein
the network interface comprises means for communicating over
TCP/IP, X.25, Serial, Modem, SNA or any other communication
format.
14. The transaction processing system as claimed in claim 1,
wherein the network interface comprises means for converting
received messages into a general standard data format.
15. The transaction processing system as claimed in claim 14,
wherein the network interface comprises a communication header
module for converting received messages into a standardised data
sequence of bytes.
16. The transaction processing system as claimed in claim 1,
wherein the card management system interface comprises a protocol
header module comprising means for converting a standardised
sequence of bytes received from the network interface into an
internal format for processing.
17. The transaction processing system as claimed in claim 1,
wherein the card management system interface comprises a protocol
header module comprising means for converting a standardised
sequence of bytes received from a communications header module into
an internal format for processing.
18. The transaction processing system as claimed in claim 15,
wherein the communication header and the protocol header modules
comprise means for sequentially checking for, receiving, converting
and routing messages and data.
19. The transaction processing system as claimed in claim 1,
wherein the communication header and protocol header modules
comprise means for routing transaction requests and responses
between the card payment network and card management system.
20. The transaction processing system as claimed in claim 1,
wherein the setup means comprises means for updating the rules
database in real time.
21. The transaction processing system as claimed in claim 1,
wherein the authorisation means comprises means for automatically
transmitting a notification to a fraud manager if a possible fraud
is detected.
22. The transaction processing system as claimed in claim 1,
wherein the authorisation means comprises means for automatically
transmitting a notification to a customer if a possible fraud is
detected.
23. The transaction processing system as claimed in claim 1,
wherein the authorisation means comprises means for automatically
transmitting a notification to a customer if an authorisation
request is rejected.
24. The transaction processing system as claimed in claim 1,
wherein the authorisation means comprises means for automatically
transmitting a notification to a customer if a request is
authorised, allowing a customer to maintain a local log of
authorised requests.
25. The transaction processing system as claimed in claim 1,
wherein said controlling means comprises an on-line banking
interface.
26. The transaction processing system as claimed in claim 1,
wherein said controlling means comprises an ATM interface.
27. The transaction processing system as claimed in claim 1,
wherein the authorisation means comprises means for receiving a
cardholder request that a card be deactivated.
28. The transaction processing system as claimed in claim 27,
wherein said means comprises means for receiving an SMS from a
cardholder.
29. A computer program product comprising software for completing a
transaction processing system as claimed in claim 1 when executing
on a digital computer.
30. A transaction processing method carried by a verification
system, and comprising the steps of (i) receiving a transaction
condition associated with a customer; (ii) writing said condition
to a condition database also storing conditions associated with
other customers; (iii) receiving a transaction authorisation
request from a transaction network; (iv) processing said received
authorisation request by dynamically retrieving a condition
associated with the customer of the authorisation request on a per
transaction basis; (v) applying said condition and determining from
the authorisation request data if the requested transaction should
be approved or denied.
Description
[0001] This is a Continuation of application Ser. No. 10/735,642,
filed Dec. 16, 2003, which in turn is a PCT continuation of
PCT/IE02/00093, filed Jun. 27, 2002 and published in English.
INTRODUCTION
[0002] 1. Field of the Invention
[0003] The invention relates to real time authorisation of
transactions using non-cash payment instruments such as credit
cards and debit cards.
[0004] 2. Prior Art Discussion
[0005] While there has been much discussion in recent years
concerning card-not-present (and particularly Internet shopping)
fraud, in fact the bulk of credit card fraud arises from
card-present transactions. For example, card "skimming" often
results in a fraudulent card being produced and used, possibly in a
different country from where the skimming occurred. Another example
is mail interception, in which cards are stolen from the postal
system as they are en route to the customer.
[0006] While the losses arising from fraud are very considerable,
efforts to date at providing new systems to reduce fraud have met
with only limited success. In one approach marketed by the company
Orbiscom..TM. a "disposable" card number is issued to which limited
use conditions are applied. This approach appears to be of benefit
for Internet transactions, however it is generally believed to be
of little benefit for card present transactions.
[0007] In another approach, "neural intelligence" is used by the
issuer to monitor proposed transactions and to block those which do
not appear to fit a usage pattern for the cardholders. These
systems monitor patterns of usage and on the basis of this
monitoring, determine when usage is out of the ordinary. While this
appears to be a very helpful approach, it suffers from practical
problems. For example, a cardholder may find to his or her
embarrassment and inconvenience that he or she can not use a card
when on holiday in a foreign country. The overall impression the
cardholder has is that he or she is not in control and does not
understand how his or her transactions are controlled.
[0008] The invention is therefore directed towards providing a
system and method for real time processing of transactions to
reduce overall fraud. Another object is to help ensure that
cardholders are more in control of how their cards are used and
that they are informed of what is happening.
SUMMARY OF THE INVENTION
[0009] According to the invention, there is provided a transaction
processing system comprising an interface for receiving
authorisation requests, an interface for transmitting authorisation
outputs, and a processing means comprising means for determining
from authorisation request data if the system output should be
positive for negative, characterised in that the processing means
comprises: [0010] a setup means comprising means for storing
transaction conditions associated with particular customers, and
[0011] authorisation means for dynamically retrieving a transaction
condition associated with the customer of each authorisation
request on a per-transaction basis and for applying said conditions
to the authorisation request.
[0012] In one embodiment the setup means comprises an interface
comprising means for allowing each customer to define said
conditions.
[0013] In one embodiment said interface comprises a Web server.
[0014] In another embodiment the setup means comprises means for
storing predefined template conditions, and for allowing a customer
to select predefined template conditions for his or her card.
[0015] In a further embodiment the setup means comprises a fraud
manager interface comprising means for allowing a fraud manager
with access control to define said template conditions.
[0016] In one embodiment the predefined template condition
comprises specific placeholders for conditions, values and logical
operators.
[0017] In one embodiment the setup means comprises input means for
allowing a customer to input customer specified parameters to the
predefined template conditions.
[0018] In another embodiment each template comprises an associated
action which is the action to be taken if, upon evaluation, the
template condition evaluates to "true".
[0019] In a further embodiment at least some of the conditions are
in the form of program code rules.
[0020] In one embodiment the setup means comprises means for
maintaining a rule database.
[0021] In one embodiment the rule database comprises means for
storing rules in a format which is indexed on a particular customer
or customer card number.
[0022] In another embodiment said rules comprise system, product
and customer rules.
[0023] In one embodiment said rules are stored in a format which
does not require parsing of logical string-based expressions for
processing.
[0024] In one embodiment the authorisation means comprises means
for automatically transmitting a notification to a customer under
control of the conditions.
[0025] In another embodiment the authorisation means comprises
means for receiving confirmation of authorisation from a customer
in response to a notification.
[0026] In a further embodiment the authorisation means comprises
means for successively applying system-level, card product-level,
and the customer conditions upon receipt of an authorisation
request.
[0027] In another embodiment the authorisation request interface
comprises a network interface for interfacing with a card payment
network.
[0028] In one embodiment the authorisation request interface
comprises a network interface for interfacing with an issuer front
end system.
[0029] In one embodiment the output interface further comprises a
card management system interface means for interfacing with an
issuer card management system.
[0030] In one embodiment the network interface comprises means for
communicating over TCP/IP, X.25, Serial, Modem, SNA or any other
communication format.
[0031] In a further embodiment the network interface comprises for
converting received messages into a general standard data
format.
[0032] In another embodiment the network interface comprises a
communication header module for converting received messages into a
standardised data sequence of bytes.
[0033] In one embodiment the card management system interface
comprises a protocol header module comprising means for converting
a standardised sequence of bytes received from the network
interface into an internal format for processing.
[0034] In another embodiment the card management system interface
comprises a protocol header module comprising means for converting
a standardised sequence of bytes received from a communications
header module into an internal format for processing.
[0035] In a further embodiment the communication header and the
protocol header modules comprise means for sequentially checking
for, receiving, converting and routing messages and data.
[0036] In one embodiment the communication header and protocol
header modules comprise means for routing transaction requests and
responses between the card payment network and card management
system.
[0037] In one embodiment the authorisation means comprises means
for updating the rules database in real time.
[0038] In another embodiment the authorisation means comprises
means for automatically transmitting a notification to a fraud
manager if a possible fraud is detected.
[0039] In a further embodiment the setup means comprises means for
automatically transmitting a notification to a customer if a
possible fraud is detected.
[0040] In one embodiment the authorisation means comprises means
for automatically transmitting a notification to a customer if an
authorisation request is rejected.
[0041] In another embodiment the authorisation means comprises
means for automatically transmitting a notification to a customer
if a request is authorised, allowing a customer to maintain a local
log of authorised requests.
[0042] In a further embodiment the setup means comprises means for
controlling customer activation of a card.
[0043] In one embodiment said controlling means comprises an
on-line banking interface.
[0044] In another embodiment said controlling means comprises an
ATM interface.
[0045] In a further embodiment the authorisation means comprises
means for receiving a cardholder request that a card be
deactivated.
[0046] In one embodiment said means comprises means for receiving
an SMS from a cardholder.
[0047] According to another aspect of the invention, there is
provided A transaction processing method carried by a verification
system, and comprising the steps of: [0048] (i) receiving a
transaction condition associated with a customer; [0049] (ii)
writing said condition to a condition database also storing
conditions associated with other customers; [0050] (iii) receiving
a transaction authorisation request from a transaction network;
[0051] (iv) processing said received authorisation request by
dynamically retrieving a condition associated with the customer of
the authorisation request on a per transaction basis; [0052] (v)
applying said condition and determining from the authorisation
request data if the requested transaction should be approved or
denied.
DETAILED DESCRIPTION OF THE INVENTION
Brief Description of the Drawings
[0053] The invention will be more clearly understood from the
following description of some embodiments thereof, given by way of
example only with reference to the accompanying drawings in
which:
[0054] FIG. 1 is a flow diagram illustrating signal transfers for
transaction processing of the invention;
[0055] FIGS. 2(a), 2(b) and 2(c) are block diagrams illustrating
alternative arrangements for connecting the components of a
verification system of the invention;
[0056] FIG. 3 is a diagram showing interaction between a front end
system and a card management system;
[0057] FIGS. 4, 5, and 6 are flow diagrams showing signalling at a
lower level;
[0058] FIG. 7 is a flow diagram illustrating processing steps in
more detail;
[0059] FIG. 8 is a diagram illustrating a database object
containing templates and cardholder rules;
[0060] FIGS. 9 to 13 are diagrams illustrating interactions between
a fraud manager and a rule database;
[0061] FIGS. 14 and 15 are diagrams showing interactions between a
fraud manager and a Web server;
[0062] FIGS. 16 to 27 are diagrams showing interaction between
people of various roles and systems of the invention; and
[0063] FIGS. 28, 29, and 30 are sample screen shots for system
displays.
DESCRIPTION OF THE EMBODIMENTS
[0064] Referring to FIG. 1, in overview, in a step A a cardholder
system 1 accesses a banking interface 2 via the Internet, although
it may alternatively be via wireless device, telephone or branch
visil The banking interface 2 is operated by an issuing bank of
which the cardholder is a customer. The interface 2 is connected to
an issuing system 3, in turn connected to a verification system 4.
The interface 2 allows the cardholder to input rules governing how
credit card transactions with her card are to be authorised These
rules can be set according to a wide variety of parameters such as:
[0065] deny if merchant is located outside of Ireland, [0066] deny
if the transaction amount exceeds EUR300, or [0067] notify me by
SMS for every transaction greater than EUR100.
[0068] The rules are updated to the verification system in a step
B, and are maintained in a rule database. They can be dynamically
varied by the cardholder or by issuer personnel such as a fraud
manager.
[0069] In a step C the cardholder initiates a purchase transaction
with her card, the transaction being handled by a merchant system
5. In a step D the merchant system 5 forwards the transaction
details to an acquiring system 6, which in step E forwards an
authorisation request to a card network device 7. In a step F the
verification system 4 executes the rules created by the cardholder
in order to pass on or deny the transaction. If passed on, the
issuing system 3 is updated in a step G, otherwise a deny signal is
transmitted in a step H.
[0070] It will be appreciated that the systems and method allow the
cardholder to be involved in the overall authorisation cycle so
that usage control is tailored to his or her requirements.
[0071] This opens up other services in addition to effective fraud
control. For example, a rule may require for an SMS notification to
be forwarded to a parent every time a card is used. This allows
parents to continually monitor and track usage for parental control
and information purposes. In effect, suitable rules can cause a
full audit trail to be generated in real time, when the information
is required and is of most benefit.
[0072] We shall refer to the sequence of FIG. 1 as being the
`authorisation chain`. It can be described as a chain because it
consists of the Merchant requesting an authorisation from an
Acquirer; an Acquirer requesting an authorisation from the network
and the network requesting authorisation from the Issuer.
[0073] This invention inserts into this chain a device whose
function is to implement Cardholder authorisation rules. This
device is located at an Issuer's premises or at a remote location
and is connected to the Issuer's systems using secure communication
means.
[0074] FIGS. 2(a), 2(b) and 2(c) show three alternative
arrangements for integrating the verification system into an
authorisation system. The main components are the verification
system (also referred to as the rule processor) 4, the card
management (Issuer) system (CMS) 3, and optionally a front end
system (FES) 10.
[0075] The function of the rule processor 4 is to decide whether a
particular request should be passed on to the issuer or declined
based on the processing of system, product and cardholder rules.
The rule processor makes this decision by evaluating rules on the
authorisation request. These rules are read in from a rule
database. Three types of rules can be entered into the rule
database: [0076] Rules that must be evaluated on every
authorisation request--`System Rules` [0077] Rules that must be
evaluated on authorisation requests that relate to payment cards
that form part of a particular product ("Product Rules"). [0078]
Rules that must be evaluated on authorisation requests that are for
particular payment cards--`Cardholder Rules`.
[0079] The CMS 3 is the terminal device in the authorisation chain.
Authorisation request responses are generated by this device. The
FES 10 interfaces with the card payment network and receives
authorisation requests. The rule processor 4 further comprises an
SMS/Email gateway 19 which allows email SMS, EMS, MMS or any other
communication format messages to be sent to the cardholders or
received from the cardholders.
[0080] Referring to FIGS. 2(a) the rule processor 4 is connected
between the FES 10 and the CMS 3. The corresponding FIG. 3
illustrates the flow of requests in this embodiment. In the normal
mode of operation, an authorisation request received from the card
payment network moves from the FES 10 and into the rule processor
4. The rule processor decides whether the authorisation request is
sent on to the CMS 3, or whether an authorisation request
response--a decline--is sent back to the network side device. The
system also supports a bypass mode of operation used by default if
a malfunction or failure is detected in the rule processor. In the
bypass mode requests are routed directly from the FES to the
CMS.
[0081] Referring to FIG. 2(b), in another embodiment the rule
processor 4 is interfaced to the FES 10. In operation,
authorisation requests from the card payment network received by
the FES 10 are routed to the rule processor 4. The rule processor
applies rules to the requests and sends them back into the FES
which decides whether or not to route them to the CMS 3.
[0082] Referring to FIG. 2(c), in another embodiment authorisation
requests are accepted from the card payment network into the rule
processor 4, where rules are applied to the requests. The rule
processor then routes permitted authorisation requests to the CMS
3.
[0083] The verification system (or rule processor) of the present
invention is designed to integrate flexibly into existing card
management (Issuer) systems. While it is possible to include
additional functionality by adding more features to a particular
`card management system` because each card management system is
different such an approach is problematic. The verification system
is designed to be placed in the authorisation chain as a separate
entity within that chain. However, in order to integrate the
verification system into existing card management systems
significant communications issues must be addressed.
[0084] FIGS. 4 to 6 illustrate the communication modules and
routing processes of the invention. ISO8583 is used over many
different types of communications media, depending on the equipment
that is being used and the preferences of the institutions
involved. These media include: [0085] TCP/IP [0086] X.25 [0087] SNA
[0088] Serial Line [0089] Modem
[0090] Messages that are sent between entities involved in the
authorisation process are standardised according to the ISO8583
standard--"Bank card originated messages--Interchange message
specifications--Content for financial transactions'. To facilitate
connection and integration of the verification system of the
invention into an existing authorisation chain a module which
converts messages from any particular medium into a "stream of
bytes" is used. This module is a CH (Communications Header).
[0091] Referring to FIG. 4 an ISO8583 Message is read by a CH
(Communications Header) from whatever form of communications
channel the incoming messages are arriving on. The message is
converted into a sequence of bytes and passed to a PH (Protocol
Header) module. The CH is a module that sends and receives data
without regard to the content It understands and implements the
specifics needed to handle connections over different media--e.g.
TCP/IP, X.25, Serial and Modem. It provides common functions for
the set-up, management and teardown of open connections. The PH
layer converts the message from a specific 8583-message
implementation into an internal `Normalised` form. This form is
independent of any vendor specific implementations.
[0092] After being processed by a `Test Rules` process of the rule
processor (described later) the message is converted from the
`Normalised` form back into a specific 8583 implementation via the
PH layer, and then is sent to its destination via the CH layer.
[0093] Referring to FIG. 5 the CH connects to its PH module. It
then attempts to connect to its 8583 source using the specified
method (TCP/IP, X.25 or Serial). It then checks whether there are
any bytes ready to be accepted from the PH module. If there are no
bytes available it immediately checks whether there are any
available from the 8583 source. If there are none, it immediately
goes back to check whether there are any bytes available from the
PH and proceeds as before.
[0094] If there are bytes available from the PH, they are read, and
sent to the 8583 source, and then checks are made for bytes being
available from 8583 source and PH as before.
[0095] If there are bytes available from the 8583 source, they are
read, and sent to the PH, and then checks are made for bytes being
available from the PH and the 8583 source as before. ISO8583 is a
standard that describes the messaging that is used to allow
organisations to exchange messages that relate to `Bank Cards`.
This specification although complete in many ways is interpreted
differently by different organisations. The differences relate for
example to the specific meaning of a field, or the choice of field
to hold a particular piece of data or how a particular response is
to be interpreted. For the invention, the implication of this
problem is that a message from one source may differ significantly
from a message from another source, not because of any difference
in the core transaction details, but because of differences between
the organisations that are feeding the transactions into the
verification system.
[0096] Because of this, a technique is presented for converting
many known implementations of ISO8583 into a single generalised
format. Examples of 8583 protocol implementations include:
TABLE-US-00001 Vendor Implementation Description VISA BASE I Visa
Credit Card implementation MasterCard CIS MasterCard Credit Card
implementation BASE 24 Host ISO ACI Credit Card implementation
Europay Host EM MasterCard Credit & Debit Card implementation
VISA SMS Visa Debit Card implementation MasterCard MDS MasterCard
Debit Card implementation
[0097] Referring to FIG. 6 the PH initially connects to a `Test
Rules` process of the rule processor. It then connects to the CH.
It checks whether there are any bytes available from the CH. If
there are not, it immediately checks whether there are any messages
available from the Application Process. If there are none, it goes
back to check for bytes from the CH and so on.
[0098] If there are bytes available from the CH, they are read and
converted into a message. At this stage, the message is in the
format of a vendor specific implementation of ISO8583. This message
is then converted into a normalised form using transformations that
are specific to this specific PH. These transformations are very
much related to each vendor's implementation and thus can be
arbitrarily complicated. For example, a particular field may be
broken down in a particular manner by a vendor implementation.
[0099] After the normalised message is generated, it is sent to the
application process. The PH then goes back to checking for bytes
from the CH.
[0100] If a message is available from an application, it is read
and converted to de-normalised form using PH transformations. It is
then converted into a sequence of bytes and passed to the CH. The
PH then goes back to checking for bytes from the CH.
[0101] Referring to FIG. 7 the authorisation cycle or "Test Rules"
process of the rule processor is shown in more detail. The request
is generated in step 101. If the number prefix is that of a valid
product (step 102) in step 104 system rules are applied. If the
output is negative in step 113 a decline response is generated.
Otherwise, in step 105 product rules are applied. If the output is
negative, again a decline response is generated. Otherwise, the
Cardholder rules are applied in step 106. Again, this may provide a
positive or a negative outcome.
[0102] The three possible outcomes of application of the sequence
of three sets of rules are: [0103] decline, [0104] approve and pass
to CMS, and [0105] create fraud queue item.
[0106] The third outcome causes an item to be added to a fraud
queue. In this embodiment, a decline outcome may cause a message to
be sent to the Cardholder (steps 116, 117, 118).
Process Messages According to Defined Rules
[0107] The Cardholder can communicate through the Issuer's computer
system. The Cardholder communicates with the Issuer's computer
system through whatever means the Issuer's computer system
supports--e.g. Internet, phone, WAP. By doing this, the Cardholder
can enter a set of rules. A rule may be in the form of IF
(Condition) THEN (Action) Each Condition can be a set of
comparisons separated by AND and OR. Each comparison compares a
authorisation request data element with a value. An example of a
condition would be: Amount>"100.00" AND(MerchantCountry="IE" OR
MerchantCountry="UK") This example condition would apply whenever
the transaction amount is greater than 100 and the Merchant is
registered in Ireland or the UK.
[0108] Each action is one of three choices--either `decline` or
`accept` or `advise Fraud Manager or advise Cardholder in the event
of an automatic confirmation system being implemented`. The term
`decline` means to not send the request onwards to the CMS, but to
send an authorisation rejection back towards the Acquirer. The term
`accept` means to send the authorisation request on towards the
Issuer. The term `advise Fraud Manager` means to send a message to
a Fraud Manager about the authorisation.
[0109] In addition to cardholder rules, the Fraud Manager in the
issuing institution can also enter rules. These rules can be
entered at three levels. The first of these is the set of rules
that are run for every transaction that passes through the
system--these are termed `system` rules. The second of these is the
set of rules that are run for each `product` that the issuing
institution markets. A product in this sense is a set of credit
card number ranges that are grouped together. The third of these is
the set of `template rules` for a particular product. These are
pre-written rules that a Cardholder who has a card from particular
product can `opt into` without having to write the rule
themselves.
[0110] The invention allows complex rules to be built and enables
them to be executed in a very time-efficient manner by using
template rules.
[0111] Each template is built in response to Fraud Manager inputs
by the Fraud Manager and is given an index number (#1, #2, . . . ).
Each template comprises a set of empty placeholders for up to ten
conditions. Each condition comprises the following: TABLE-US-00002
Template index Number Unique identifier for this template. Field
Number Number of field in message Eg `Field32 could be Merchant
Country` Condition Condition to apply to field Eg - `equals`/`does
not equal`/`is less than`/`is greater than` Value Value to compare
against Logical Operator Operator to use with next condition Eg -
`AND`/`OR`
[0112] Also associated with each template is an `Action`. This is
the action to take if the condition evaluates to `True`. Each
action is composed of the following elements: TABLE-US-00003 Event
Event that should take place Eg - `Decline`/`Approve`/`Advise`
Direction Direction to send message Eg - `Forward`/`Back` Response
Code Value to set in `Response Code` field of message. Eg - `01 -
refer to Card Issuer`
[0113] Each template also includes `Notification` fields. These
fields indicate whether an Email or SMS notification should be sent
if the condition above evaluates to `True`.
Cardholder Rules
[0114] Each cardholder rule comprises a reference to a template and
any information required by that template. Accordingly, the fields
involved are: TABLE-US-00004 Card Number The unique number of the
card Template The number of the template to which this rule refers.
Parameter1 If any conditions for this template require a parameter
(eg Template condition is `Amount >= User_Specified_Amount), the
first of these parameters is stored here. Parameter2 As Parameter1
above. SMS Address SMS Address of this cardholder if required.
Email Address Email Address of this cardholder if required.
Sequence Sequence in which the rules associated with this
cardholder should be executed.
[0115] All of the cardholder rules in the system are stored in the
system database and are indexed and clustered on card number.
Real Time--not Batch
[0116] The invention allows Cardholders and Fraud Managers to view
and modify rules while, at the same time, processing authorisation
transactions using these rules. Updates to the rules can be made in
real time with the effect of such a change being immediate.
[0117] In order to allow this to occur, `database transactions` are
defined for the purposes of reading and updating the table in which
rules are stored. The purpose of these transactions is to allow
updates to rules to occur in the moments between one authorisation
transaction and the next.
Processing Efficiency
[0118] The processing efficiency of the system is based upon the
time taken to read all rules related to a particular card out of
the database and the time taken to computationally apply the rules
to the transaction in hand.
[0119] By having cardholder rules refer to templates rather than
exist in a stand-alone manner makes each cardholder rule very small
(<100 bytes). This means that a minimal amount of disk space
will be used per rule, and so more rules can be read per database
read.
[0120] By clustering the cardholder rules within the database on
Card Number, all rules related to a particular Cardholder can be
read in one disk read by the database.
[0121] By allowing templates to have specific placeholders for
conditions, values and logical operators there is no requirement
for the normal parsing of logical string-based expressions.
Processing can proceed without the need for intensive string
parsing.
[0122] Referring to FIG. 8, an example of a database object
containing two templates and two sets of Cardholder rules is
illustrated. [0123] Template #1 contains the rule: [0124] IF
(Field32=`Africa` OR Field32=`Asia` OR Field32=`Australia`) [0125]
THEN [0126] Sent Decline Back with Response Code 2 [0127] Send SMS
and Email to Cardholder [0128] Template #2 contains the rule:
[0129] IF (Field41.2=`20` OR Field41.2=`20) [0130] THEN [0131] Send
Decline Back with Response Code 2 [0132] Cardholder Rules for card
`1234123412341234`: [0133] IF (Card Number is `1234123412341234`)
[0134] Apply Template 1 with no parameters, [0135] and SMS Address
0872337868 [0136] and Email Address joebloggs@aol.com [0137] Apply
Template 2 with no parameters, [0138] and no SMS Address [0139] and
no Email Address [0140] Cardholder Rules for card
`9999999999999999`: [0141] IF (Card Number is `9999999999999999`)
[0142] Apply Template 1 with no parameters, [0143] and SMS Address
0872337868 [0144] and Email Address joebloggs@aol.com
[0145] FIGS. 9 to 25 illustrate how Issuer Personnel and
Cardholders interact with the rule processor.
[0146] Users of the system are as follows: TABLE-US-00005 User Role
Cardholder The Cardholder is a person who holds a credit card,
which has been issued by the Issuer. The invention primarily allows
the Cardholder to add rules that control how his/her card is used.
Fraud The Fraud Manager is an employee of the Issuer. The invention
allows this Manager person to add rules to particular control how
particular credit card products operate. This can be done in order
to reduce Fraud, or in order to create new types of credit card
products with different operating profiles. CSR The Customer
Service Representatives answer queries from Cardholders. The
invention allows CSRs to perform all of the tasks that a Cardholder
can perform. Also, the CSR is able to view details on the
authorisation requests and responses for particular cards over
given time periods. Technical The Technical Operator is responsible
for starting and stopping the system, Operator editing database
data, applying new configuration data to the system and checking
the status of the system. Auditor The Auditor's is allowed see, at
a great level of detail the decisions being made by the system, and
is able to trace these decisions back to individual messages and
rules.
[0147] The Fraud Manager is that person in the Issuing Institution
whose function is to track and minimise the incidence of fraud in
the institution. This person and the Cardholder are the prime users
of the system 4. The Fraud Manager configures the system 4
according to the needs of the Issuer. FIGS. 9 to 15 illustrate some
interactions of the Fraud Manager with the system.
Fraud Manager Adds or Modifies Products (FIG. 9)
[0148] The Fraud Manager must define those products that the Issuer
uses. A product is a set of credit cards that a Fraud Manager
wishes to view as a single entity for the purpose of applying rules
to them. These may in fact be individual products that the Issuer
offers its customers (e.g. Standard Card, Gold Card, Platinum
Card,) or they may be collections or subsets of same.
Fraud Manager Adds or Modifies BIN (FIG. 10)
[0149] Each Issuer has a set of allocated credit card number
prefixes (Bank Identifier Numbers or `BIN's). In the natural course
of events, it divides these up between the products that it
creates. For instance, it might create a student credit card
product, a normal credit card product and a gold credit card
product. These products, and their associated BIN's are entered
into the system as part of the product definitions.
Fraud Manager Modifies System or Product or Template Rules (FIG.
11)
[0150] The Fraud Manager can add rules to the system 4 of types
`System`, `Product` or `Template`. Rules lie at the core of the
system 4 and are in three types. Each rule type is applied in the
following order to each authorisation request message: [0151]
System Rules are applied to all messages arriving from the network.
[0152] Product Rules are applied to all messages in particular BIN
ranges arriving from Network. [0153] Cardholder rules are applied
to all messages that relate to a particular credit card number. A
Cardholder rule can be created in one of two ways: [0154] It can be
created by the Fraud Manager as a template rule, and can then be
opted into by the cardholder. For example, the Fraud Manager might
create a template rule that defines how to reject a transaction if
the Merchant is not a European merchant. A Cardholder might then be
asked whether they wanted to `switch on` this rule on their card.
If they decide to, a new rule is generated for them, based on the
template rule. [0155] The Cardholder can generate it directly.
Fraud Manager Modifies Rule Sequence (FIG. 12)
[0156] The order of execution within each set of rules (system,
product and cardholder) can be modified by the Fraud Manager as
required.
Fraud Manager Views Cardholder Rules (FIG. 13)
[0157] The Fraud Manager can view but not modify Cardholder rules.
A "PAN", is the industry term for a credit card number ("Primary
Account Number").
Fraud Manager Reviews Fraud Queue and Acknowledges an Item (FIG.
14)
[0158] A fraud queue is a queue of issues that Fraud Managers go
through on a regular basis. These issues are those items that have
matched rules whose action was `Advise Fraud Manager` or `Decline`.
Each item on the fraud queue has to be acknowledged by a Fraud
Manager. Several different Fraud Managers can be looking at the
fraud queue and acknowledging items at the same time.
Fraud Manager Requests Report (FIG. 15)
[0159] The Fraud Manager can get various reports from the system 4.
These can relate to fraud queue, activated rules, tracked rules,
active rules, and suspended rules.
Fraud Manager Sets up System Options (FIG. 16)
[0160] There are various system settings that the Fraud Manager
needs to set up. These settings are global, i.e. in that they apply
to all products. [0161] Monitor only without declining [0162]
Archival Options--when to archive and how old items must be before
they are archived.
[0163] FIGS. 16 and 17 illustrate how a cardholder can interact
with the system. The Cardholders can enter rules themselves. One
way that they can do this is by choosing to have a particular rule
from a template enabled. The list of templates available to a
Cardholder whose payment card is part of a particular product might
be: [0164] Deny Access Outside Ireland [0165] Deny Access Outside
Europe [0166] Deny Access Outside Europe and US [0167] Deny Access
to Internet Merchants [0168] Deny All Transactions unless Specified
[0169] Deny All Internet Transactions unless Specified [0170] Allow
One-Time Transaction for (.English Pound.50, .English Pound.100,
.English Pound.500, .English Pound.1000)
[0171] Alternatively, the Cardholder can define a Rule from scratch
in the same way that the Fraud Manager defines one.
Cardholder Requests List of Templates Available for Credit Card
number, and Adds One (FIG. 16)
[0172] The invention provides the interface to the Issuer's online
banking system. This interface is web-based, although it is not
expected that the web interface is delivered directly to the
Cardholder. Rather, it is expected that the web-based interface is
driven by the Issuer's computer systems. Here a list of template
rules is provided, from which the Cardholder can add one or more
for their particular credit card.
Cardholder Requests List of Current Rules for Cardholder and can
Delete One (FIG. 17)
[0173] Referring to FIG. 17, the Cardholder requests a list of
current rules available and selects the option to delete one. The
Cardholder requests the set of rules that are set up for a
particular PAN. The Cardholder can then optionally delete one of
these rules.
[0174] The Cardholder generates a new rule rather than choosing
from a list of pre-defined template rules and applies this rule to
the credit card.
[0175] As shown in FIG. 18 the system supports access by a Customer
Service Representative. The Issuer's CSR (Customer Service
Representative) can perform all functions that a Cardholder can
perform as well as one other. The same interface is used for CSR
functions as is provided for Cardholder functions. It is expected
that an Issuer's existing CSR application will be integrated to
allow this extra functionality.
[0176] Referring to FIG. 18, the CSR can see logged activity for a
credit card number over a time range. The CSR can look into a
particular item and see the underlying message if available.
Functional Requirement--Allow Auditor to Verify Integrity of
System
[0177] The Issuer's auditors--internal and external--must be able
to see how and why the software functions in the way that it does.
The overall functionality of the system is to allow Issuers and
Cardholders to selectively decline transactions, so the reason for
a transaction either being declined or not has to be clear to an
Auditor.
Auditor Views Transaction Log (FIG. 19)
[0178] The Auditor can look into the transaction log to see the
detail of the processing of the system.
Auditor Examines One Particular Set of Rules in Detail (FIG.
20)
[0179] The Auditor can enable rule tracking, which enables the
Auditor to track all of the decisions relating to a particular
rule. When rule tracking is switched on the Auditor will see each
condition being tested and the result of the test.
Functional Requirement--Allow Technical Team to Control and
Configure System
[0180] The Technical Operator has the job of configuring the system
for use, and maintaining it thereafter. Most of this configuration
resides in the database. However, it would be inefficient for the
processing nodes to have to read their own configuration from the
database. Instead their configuration is loaded into a local
database on each processing node. This means that there is a
requirement for parts of the database to be loaded into the local
database on each processing node by the Technical Operator.
Technical Operator Modifies Database through Web Browser (FIG.
21)
[0181] The Technical Operator can modify all tables in the database
through a web browser.
Technical Operator Starts/Stops Processing Nodes (FIG. 22)
[0182] The Technical Operator uses an application to allow the
starting and stopping of each processing node 15.
Technical Operator Sends New Configuration to the Processing Nodes
(FIG. 23)
[0183] The technical operator must instruct the processing nodes to
begin using the new registry that they have been sent, This is
achieved with this use case.
Technical Operator Triggers the Processing Nodes to Begin Using a
New Configuration (FIG. 24)
[0184] The technical operator must instruct the processing nodes to
begin using the new registry that they have been sent, This is
achieved with this use case.
O&M Node Checks Status of Processing Nodes (FIG. 25)
[0185] The O&M Node sends a status request message once every
10 seconds to each O&M node. The O&M node replies with a
response, and on the basis of this, the O&M Node database entry
is updated.
Functional Requirement--Perform All System Maintenance Functions
Automatically
[0186] At the end of each period (such as a day), the system 4 must
run several procedures automatically.
Database is Backed up (FIG. 26)
[0187] The database is backed up to tape on a nightly basis.
Database is Restored (FIG. 27)
[0188] The data on tape can be restored into the database.
[0189] The system 4 generates a large number of messages and logged
items. These objects are taken out of the database after they have
been there for a period of time in order to prevent the database
from growing too large. Over time, the expired rules (rules that
are past the end of their stop date) must be archived. Management
information (MIS) reports are run from a different database server.
Entities relevant to MIS reports are copied into a separate
database.
Fraud Alarm/Rejection Alarm/Authorisation Confirmation
[0190] This invention allows notifications (SMS/email) that are
sent to cardholders to serve different functions: [0191] They can
be configured to act as a `Fraud Alarm` [0192] Rules are set within
the rule processor to prevent fraud. When a rule infringement and
possible fraud is detected, a fraud alarm can be triggered and a
notification sent to the cardholder in order to alert them of
possible fraud. [0193] They can be configured to act as a
`Rejection Alarm` [0194] A notification can be sent to alert the
cardholder about a transaction that has been declined for a reason
other than the infringement of a rule. For instance, if the card
management system decides that a particular transaction would push
a cardholder over their credit limit, it normally does this
silently. However, the invention can be configured to see this
rejection and to send a message to the cardholder informing them of
the rejection. [0195] They can be configured to act as an
`Authorisation Confirmation` [0196] A notification can be sent to a
cardholder whenever a transaction is approved. A cardholder may
wish to use this feature to maintain an email log of all
transactions on a card.
[0197] The invention can be configured to see all approvals and to
send a message to the cardholder informing them of the
approval.
Card Activation
[0198] Much credit card fraud exists in the form of "Mail Fraud".
This fraud occurs when a fraudster intercepts a latter containing a
credit card, which is on the way to a cardholder.
[0199] In order to eliminate this form of fraud, the system 4 can
establish rules denying the use of each recently issued credit card
until an activation event occurs. This activation event can have a
number of forms: [0200] The cardholder goes to an ATM machine and
enters the new card followed by the allocated PIN. A transaction is
then sent to the issuing bank from the ATM. This transaction is
specially formatted to that when the transaction goes through to
the processor of the invention, the processor deactivates the rule
that is denying the card use. The card is thus "Activated". [0201]
Alternatively the cardholder could use his/her computer to access
and switch off the rule that is denying the card's use. The card
can be thus activated. Online-Banking Access
[0202] The invention allows rules to be accessed by Cardholders
through an online banking platform. The online banking platform is
responsible for construction of credit card management web page.
The online banking platform calls the verification system in order
construct the required web page.
[0203] The verification system of the invention provides four
services to the online banking platform to aid it in constructing
the card management web page: [0204] List all rules that a
Cardholder can switch on. [0205] Display all rules that a
Cardholder can switch off. [0206] Switch a rule on. [0207] Switch a
rule off.
[0208] Referring to FIG. 28, a screen of the interface 2 is shown,
the screen shown is an example of a basic rule activation screen.
The customer can access this screen through their online banking
channel, at an ATM, or through a customer representative. This
basic rule activation is part of the existing renewal or
registration process. For example the Issuer may inform the
Cardholder that their card will not operate in a specific
geographic region that may be sensitive to fraud unless the
Cardholder informs them to the contrary by telephone or online that
there are specific countries that they wish to "turn on".
[0209] In another application, as shown in FIG. 29, a customer
segment uses the verification system through the card product they
have chosen to use i.e. where the card product has predetermined
parameters e.g. transaction type or geographic set to Issuer
determined defaults when the card is issued but changed by the
Cardholder to suit their own particular requirements whether it is
security or control they are concerned about.
[0210] These products are designed for Cardholders who may wish to
have more active participation in how a card is used, for example,
an ancillary card issued by a parent to a child where the parent
wishes to control how, where and when the card is used by the
child. FIG. 29 illustrates an example of a parent controlled
teenager card and how the verification system enhances the security
and control for the parent.
[0211] The card product design of this particular customer segment
would be driven by specific customer needs for credit control and
security. An example of this would be a corporate Card Manager as
detailed in FIG. 30. Designed for the corporate market where a
financial controller may wish to centrally control the individual
usage profiles of the company's payment card base using rules
similar to previous examples. Rules could also exclude specific
merchants or alternatively may allow the card to be used only at
specific merchants i.e. as a controlled purchasing card.
[0212] Transaction rules form an important part of the operation of
card management systems by card issuers. These are rules that are
usually applied at either a system level i.e. a rule that will
apply to all cards issued by that institution or at a product level
i.e. a rule that will apply to a particular card product such as a
Gold Card. An example of a rule might be to deny or refer all
transactions from a country that is deemed to be a particular
hotspot for card fraud.
[0213] It will be appreciated that the invention allows the
cardholder to control what happens in the authorisation process via
the establishment of a rule set that will apply to all cardholder's
transaction. The cardholder can remotely create, delete or amend
rules e.g. through online banking channels. In addition the
invention at the Issuers discretion allows for the cardholder to be
alerted in real-time of a rule infringement thus alerting him to
potential misuse of their payment card and allows them to respond
automatically to this alert in real-time to confirm their
authenticity thus allowing the transaction to proceed.
[0214] It is expected that the invention will reduce and displace
the incidence of fraud in payment card networks. It effectively
helps manage the risk of card fraud. The system can be used as a
complementary technology and as such the card Issuers can implement
it as another line of defence in the fight against fraud.
[0215] The invention is not limited to the embodiments described
but may be varied in construction and detail.
* * * * *