Method and system for determining point of sale authorization

Abstract

According to an embodiment of the present invention, an automated computer implemented method and system for determining authorization for a point of sale transaction, wherein the method is executed by a programmed computer processor which communicates with a user via a communication network comprising receiving a point of sale authorization request for a transaction from a customer at a merchant, via a communication network; accessing profile data associated with one or more of the customer, an account associated with the customer and the merchant involved in the transaction; applying one or more rules to the authorization request wherein the one or more rules comprises one or more of credit rules and fraud rules; applying one or more scoring algorithm to the authorization request wherein the one or more scoring algorithm indicates an assessment of risk; determining an authorization response, via a programmed computer processor, based at least in part on a combination of profile data, the one or more applied rules and the one or more applied scoring algorithms; providing the authorization response for the transaction via the communication network.

Description

FIELD OF THE INVENTION

The present invention relates generally to point of sale authorizations, and more specifically to a method and system for providing enhanced point of sale decisions for customers and providers where multiple data types are analyzed and considered in addressing each transaction.

BACKGROUND OF THE INVENTION

Currently, point of sale (POS) systems generally approve all transactions and address fraudulent transactions well after the transaction has been completed. Most merchants will more often than not approve a majority of the transactions. If transactions are declined, they are declined without much intelligence. In determining whether to authorize a transaction, the current systems usually only focus on one factor: the customer's credit for that card, without regard to other factors and considerations. As a result, current systems do not accurately authorize and decline transactions, which result in inefficiencies, approval of fraudulent charges and lost revenue.

Other drawbacks may also be present.

SUMMARY OF THE INVENTION

Accordingly, one aspect of the invention is to address one or more of the drawbacks set forth above. According to an embodiment of the present invention, an automated computer implemented method for determining authorization for a point of sale transaction, wherein the method is executed by a programmed computer processor which communicates with a user via a communication network, comprises the steps of: receiving a point of sale authorization request for a transaction from a customer at a merchant, via a communication network; accessing profile data associated with one or more of the customer, an account associated with the customer and the merchant involved in the transaction; applying one or more rules to the authorization request wherein the one or more rules comprises credit rules and fraud rules; applying one or more scoring algorithm to the authorization request wherein the one or more scoring algorithm indicates an assessment of risk; determining an authorization response, via a programmed computer processor, based at least in part on a combination of profile data, the one or more applied rules and the one or more applied scoring algorithms; providing the authorization response for the transaction via the communication network.

According to an exemplary embodiment of the present invention, an automated computer implemented method and system for determining authorization for a point of sale transaction further comprises: wherein the profile data comprises geographic location of one or more of the customer, the merchant and a card product associated with the customer; wherein the profile data comprises travel advisories and purchase advisories associated with the customer; wherein the one or more scoring algorithm comprises credit risk and fraud risk; wherein the fraud risk is based on one or more of fraud events and fraud trends; wherein the one or more scoring algorithm comprises one or more of profitability, spend utilization and attrition; wherein the authorization response comprises one or more of memo on account, queue for credit review, queue for fraud alert; wherein the authorization response comprises one or more contact customer and flag account for suspected fraud; further comprising the step of generating one or more reports demonstrating decision and action metrics associated with historic POS authorizations; and further comprising the step of storing data associated with the transaction in an authorization log, wherein the data comprises the authorization response.

According to an exemplary embodiment of the present invention, an automated computer implemented system for determining authorization for a point of sale transaction comprises: an interface for receiving a point of sale authorization request for a transaction from a customer at a merchant, via a communication network; a profile module for accessing profile data associated with one or more of the customer, an account associated with the customer and the merchant involved in the transaction; a rules module for applying one or more rules to the authorization request wherein the one or more rules comprises credit rules and fraud rules; a scoring module for applying one or more scoring algorithm to the authorization request wherein the one or more scoring algorithm indicates an assessment of risk; and a decision engine for determining an authorization response, via a programmed computer processor, based at least in part on a combination of profile data, the one or more applied rules and the one or more applied scoring algorithms; and for providing the authorization response for the transaction via the communication network.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to facilitate a fuller understanding of the present inventions, reference is now made to the appended drawings. These drawings should not be construed as limiting the present inventions, but are intended to be exemplary only.

FIG. 1 is an exemplary diagram of a system for processing point of sale authorization requests, according to an embodiment of the present invention.

FIG. 2 is an exemplary flowchart illustrating a method for processing point of sale authorization requests, according to an embodiment of the present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

An embodiment of the present invention is directed to an infrastructure to deliver optimal point of sale (POS) decisions for customers and other users. POS decisioning may include the ability to interact with a customer in advance of an authorization request, during the authorization decision process, and subsequent to an authorization decision. Interactions with the customer may occur via various modes of communication, including in-person, merchant location, telephone, Internet, electronic communication, etc. An embodiment of the present invention improves the ability to make more accurate and well informed decisions by providing predictive data and more precise rule sets.

An embodiment of the present invention is able to recognize customer profile data, card product type, merchant data, account data, geographic data and/or other relevant information at the point of sale to provide accurate and comprehensive decisioning. In addition, an embodiment of the present invention analyzes fraud data to recognize fraud trends and other behavior at the point of sale for each transaction. Thus, an embodiment of the present invention may balance the dimensions of credit and fraud risk, customer experience, the cost of delivering an appropriate POS authorization decision and/or other factors—all of which may be dynamic.

An embodiment of the present invention provides greater precision in transaction decisions. A method and system of an embodiment of the present invention may introduce a richer set of data into the decision process (e.g., customer, card and merchant behavior profiles, etc.) Also, better controls and monitoring of strategizes may be realized.

An embodiment of the present invention may create, support, and leverage comprehensive, time-based data views of customers, accounts, merchants, geographies, transactions and/or other data. According to an exemplary embodiment, the system and method may provide tools and processes that allow an entity to manage complex and evolving POS strategies via acts of configuration carried out by business analysts, strategy managers and/or other participants. An embodiment of the present invention may provide the ability to support rich, real-time analysis and reporting tools that inform managers and/or other participants on the health of the POS operating environment and the running performance of executing POS strategies. An embodiment of the present invention may receive inputs and send updates to a variety of source and target data stores and systems and may further incorporate data and notifications from new sources through an integration process.

For example, an embodiment of the present invention may recognize the customer, card and account at the point of sale and make comprehensive intelligent decisions regarding the underlying transaction. In addition, an embodiment of the present invention may also consider merchant data related to the transaction as well as geographic data of the customer, merchant, card, etc. For instance, an embodiment of the present invention may recognize that a particular card present transaction occurred in California and another subsequent card present transaction occurred in New York a short time later (e.g., one hour, etc.) on the same card. The geographic and temporal considerations would mark this transaction as being improbable. In other words, fraud may be likely involved.

According to another example, a customer's behavior may indicate an upcoming trip to Europe for two weeks. This may be evident by the customer's purchase of airline tickets and hotel reservations and/or other behavior. In another example, the customer may provide this information to a system. Using this information, the system of the present invention may deny and/or flag any in person transaction that occurs in the U.S. or other area outside of Europe during the two week period.

FIG. 1 is an exemplary diagram of a system for processing point of sale authorization requests, according to an embodiment of the present invention. A system 100 of an embodiment of the present invention may include a Decision Engine 120, which may be stand alone, hosted by an entity, such as a financial institution, service provider, bank, etc. For example, Decision Engine 120 may be affiliated or associated with a financial institution, bank and/or other entity with POS authorization concerns. In an exemplary embodiment involving a financial institution, the financial institution may host or support Decision Engine 120. In this example, POS authorization decisioning in accordance with an embodiment of the present invention may appear to be performed by financial institution, as a single consolidated unit. According to another example, Decision Engine 120 may be separate and distinct from a financial institution. For example, a financial institution, or other entity, may communicate to Decision Engine 120 via a network or other communication mechanism.

Point of Sale 110 may represent a point of sale location, such as a merchant location, online website and/or other purchasing interface. A merchant or other intermediary may transmit an authorization request from Point of Sale 110. An embodiment of the present invention may provide an interface for various transaction sources and controls for which data, scores and rules are applied. Association Interface 112 may receive an authorization message from a card association or other intermediary or even directly from Point of Sale 110. Association Interface 112 may decrypt the message and convert the message to an internal format. Association Interface 112 may manage priority of messages passed to Transaction Controller 114. For example, some messages, such as association authorizations, may have higher priority over other messages, such as pay float. According to another example, POS 110 may communicate directly or indirectly with Decision Engine 120.

Decision Engine 120 may perform various functions, such as data enrichment, basic check execution, complex decisioning, profile update, decision result recordation, post activity request, and/or other functions. Decision Engine 120 may access and communicate directly or indirectly with Scoring Module 130, Rules Module 132, Profiles Module 134, Post Decision Activity Module 136, Authorization Log 140, Database 142, Authorization Controls 146, and/or other modules and/or sources of data. Communication between each representative component may be electronic, wireline, wireless and/or other mode of communication. In addition, Decision Engine 120 may have access to other sources of data and/or data feeds that identify other metrics and/or information that may be relevant for POS authorization decisioning in accordance with the various embodiments of the present invention. While a single illustrative block, module or component is shown, these illustrative blocks, modules or components may be multiplied for various applications or different application environments. In addition, the modules or components may be further combined into a consolidated unit. Other architectures may be realized. The modules and/or components may be further duplicated, combined and/or separated across multiple systems at local and/or remote locations.

Decision Engine 120 may access various sources of information to perform comprehensive decisioning on point of sale authorization requests for transactions. For example, Decision Engine 120 may access and/or maintain Database 142. Database 142 may include data, such as account information, transaction activity, payment activity, and/or other relevant data for one or more accounts. While a single database is illustrated in the exemplary figure, the system may include multiple databases at the same location or separated through multiple locations. The databases may be further combined and/or separated. In addition, the databases may be supported by a financial institution or an independent service provider. For example, an independent service provider may support the one or more databases and/or other functionality at a remote location. Other architectures may be realized. The components of the exemplary system diagrams may be duplicated, combined, separated and/or otherwise modified, as desired by various applications of the embodiments of the present invention as well as different environments and platforms.

An embodiment of the present invention provides data access and integration capabilities of data sources in a batch process, but also in real time processes. The sources of data may range from data warehouse stores, to other operational systems, mainframe or new variables calculated mid authorization stream, but is not limited to this. An embodiment of the present invention may hide details of specific physical data payloads from business functions and allow new data elements to be incorporated, created, and used by POS business functions with rapid deployment, eliminating dependency on integrated technology release management. Incorporation of new data from existing or new sources may also be included.

As illustrated by Scoring Module 130, an embodiment of the present invention provides scoring capabilities that provide assessment of credit risk, fraud risk, profitability, spend utilization, attrition, ability to contact, and/or other values and probabilities. For example, scores may represent an estimate for a prediction, such as probability of fraud or credit default. Scores may by represented by a numerical value or other indication of probability. Any authorization request may involve the invocation of one or multiple scoring functions. Scores produced as outputs by one model or calculation may serve as inputs to a subsequently executed model, calculation or to the rules portion of the decision. Scores related to a particular authorization request may be calculated before, during, or after the authorization response process and in batch, real-time and/or other operational modes. An embodiment of the present invention allows for the rapid deployment of new scoring calculations as well as the easy incorporation of new data elements and sources into the scoring environment.

An embodiment of the present invention may consider fraud data and trends in the POS authorization decisioning process. For example, an embodiment of the present invention may have access to monitoring data related to fraud events and the ability to recognize fraud trends and apply these trends to the decisioning process.

As illustrated by Rules Module 132, an embodiment of the present invention provides a business-friendly environment for the development, testing, and deployment of various business rules and business functions for POS decision strategies. For example, rules may be used for segmentation. Rules may identify what spend level a customer belongs to, payment behavior, transaction type (e.g., card present, card not present), where the customer prefers to shop, types of transactions (e.g., merchant, Internet, restaurants, entertainment, etc.) and/or other segmentation. Also, rules may be applied to scores to translate probability into one or more actions concerning the transaction, such as approve, defer, decline, customer review, other action and/or combination thereof.

Segmentation data produced by rules may be used to identify and avoid fraudulent charges. For example, a merchant may be an Internet only merchant, which means that the merchant only conducts online transactions. If a card present transaction for this particular Internet only merchant shows up on a customer's card, this purchase may indicate a fraudulent activity. In response, an appropriate action may involve flagging or banning all card present transactions at this Internet only merchant. Also, the actions may consider risk assessments. For example, if a possible fraudulent activity is detected, all transactions may be banned at a merchant with high risk whereas all transactions may be approved at a merchant with low risk. For the merchant with low risk, a customer contact for confirmation may be initiated for the approved transactions.

Any given authorization request may utilize rule execution prior to, subsequent to and/or simultaneously with score execution. An embodiment of the present invention may allow rule changes and updates to be applied to the production environment, through a controlled process, on a daily or other basis. Business rules and functions may support arithmetic and logical operators as well as mathematical, statistical, string and/or other functions. Rules may be callable from other rules and it may be possible to invoke multiple rule sets in response to a single authorization. Additionally, rules may initiate actions on operational systems. Targeted actions may include but are not limited to: account blocking, recording information in support of future decisions, queuing a transaction for review by an operational process, initiating customer communication or customer treatments and/or other actions.

As illustrated by Profiles Module 134, an embodiment of the present invention may access profile information, such as customer data, customer preference, card product data, merchant data, account data, geographic information and/or other data. An embodiment of the present invention may provide or be able to leverage a data storage environment capable of hosting operational data profiles representing Account, Customer, Card, Merchant, Customer Geography, and Transaction business entities for use by POS strategies. Profiles may accept updates on time intervals ranging from monthly (e.g., account cycle, etc.) to daily to, in some cases, sub-second (e.g., transactional, etc.).

Profile data may include data related to card, account, customer, merchant, geography, card merchant, account/merchant, account/geographic, non-authorization profile updates, specialty profiles, etc. Customer profile may include variables defined at the customer level including credit line, balance, status, tenure, payment behavior, outstanding authorizations, cash line, cash balance, balance transfer/convenience check (BT/CC) balance, number of cards, product, relationship, customer value, average number of transactions per day, average spend per cycle, max spend per day, max spend per cycle, and other variables.

For example, an embodiment of the present invention may recognize that a single account may be associated with multiple card products, with different account numbers and even different names (e.g., members of a family). POS authorization decisions may consider a customer's card behavior relative to a particular card product as well as other activity associated with other cards and accounts. For example, a customer's card activity may be considered as well as the customer's spouse's activity on a different card product and/or other cards associated with the account (e.g., daughter's debit card, etc.).

Various identifiers, such as card number, zip code, merchant name, merchant ID and/or other data may be used to identify associated profiles and authorization controls. For example, a card number may be used to identify customer's card, type of card, account and customer profiles. Zip code may be used to identify a geography profile. Merchant name and/or identifier may be used to access a merchant profile. Intersection profiles, such as card/merchant, card/geography, may also be identified. For example, a card/geography interaction profile may consider where a card has been used and relevant activity in that particular location. In this example, whether the card has been used in a particular geographic location may be considered. A risk assessment may be performed or determined on the geographic location. For example, a customer may reside in Delaware. It may be determined by his profile and other data that he does not travel beyond the east coast. If a card present transaction is detected in California, an embodiment of the present invention may determined that this particular card has never been to California. It may also determined that the merchant in California involved in the transaction has a higher than normal fraud rate. With these factors in consideration, an embodiment of the present invention may then determine an appropriate action, such as deny and/or flag the potential fraudulent activity. Associated records from authorization control tables may also be identified, such as yellow flags, travel advisories, purchase advisories, safe zones, guaranteed approval, etc.

An embodiment of the present invention may focus on the card and track where it is being used. This data may be used to create and/or refine a customer's profile data. For example, a customer residing in 12345 zip code may use the card at a particular restaurant. By applying a fraud rule, the system may recognize that other customers living in that same zip code also dine at that restaurant and thereby deem those transactions valid. The system may continue to monitor the customer's behavior and continue to approve transactions within the recognized zip code. If transactions start showing up in other locations, those transactions may be flagged or declined. As the system develops and refines the customer's profile, the system may recognize that the customer visits family two hours away each month. The system may recognize this as a safe zone and authorize all transactions in that area during the recognized time frame. The system may also recognize that families travel more often during the summer months when school is out of session. So, for the summer months, the system will approve more transactions outside the local zip code. Also, the system may recognize that the customer travels to San Francisco every August. Accordingly, these transactions will be authorized in this location during the travel time period. According to another example, an embodiment of the present invention may recognize business travels where the customer makes travel and hotel arrangements for himself or herself, without additional family members. Also, a customer may have a designated business card product for business purchases. An embodiment of the present invention may recognize that different geographies are more likely for business travel as opposed to personal travel. Accordingly, those business related purchases will more likely be approved, even if occurring in various geographic locations. Other variations and applications may be applied.

An embodiment of the present invention may view data that could have been used to decision an authorization at the time of processing, not just the data that was actually used by the rules sets that were executed. Capturing all the data as part of the decision log permits an embodiment of the present invention to easily simulate the impact of new rules and scores.

Database 142 may support a complete record of data used to process an authorization request or other decision type as well as a complete trace of rules and scores used in the process. Information captured and retained as the result of an authorization decision may be available for use by analytic and operational processes. Database 142 may also receive External Data 144 from various sources. While a single block is shown, external data may represent multiple sources of data. For example, Database 142 may receive good indicators, bad indicators as well as neutral indicators. Good indicators may include recency of payments, time passed with no fraudulent activities, etc. Bad indicators may include fraud reported by customers, lack of payment from customer, missed or late payments, loss of income, etc. Other data may include fraud occurring elsewhere, notifications from merchants, police reports, credit bureau reports, reports from other entities (e.g., issuers, loan agencies, etc.), macro economic data (e.g., state of unemployment, stock market, etc.) and/or other data. Data from financial institutions may also be used. For example, a customer may have an automatic deposit with an employer twice a month. If the automatic deposit has been terminated, the customer's credit default risk may increase. Partner data from various entities (e.g., travel and entertainment agencies) may also be received. This data may be used to identify travel patterns and other customer behavior data.

As illustrated by Reports Module 136, an embodiment of the present invention may provide and/or support real-time dashboards, standard reports, and ad hoc queries and reports that present metrics on the overall health and performance of the technical operating environment as well as the decision and action metrics of executing POS strategies. Dashboard, reporting, and query capabilities may be accessible by a broad range of analytic and operational stakeholders including IT, Strategy Management, Marketing and/or other entities. The Management Information System (MIS) metrics set may be extensible via business configuration or development processes. An embodiment of the present invention may support high-level summarization and drill-down across a configurable range of dimensions and filters including but not limited to customer, account, product, business unit, transaction type, merchant and/or other factors. An embodiment of the present invention may support temporal aggregation intervals ranging from seconds through minutes, hours, days, weeks, and months to yearly aggregations. An embodiment of the present invention may also provide an environment that allows business strategy managers to define Event Detection Rules that may be monitored and enforced by the Analytic Data Storage environment and then communicated to the Decision Engine environment for handling by POS strategies and rules. Defined events to be supported may include customer spending outside of normal geographic and merchant footprints, spending velocity pattern changes, and other “out-of-band” behaviors that may be defined over Customer, Account, and/or Merchant data footprints.

A user may access the Reports Module 136 via a user interface. Reports and other outputs may be transmitted via wireless communication to remote devices. Users may program and execute customized reports on a periodic basis or by request. Other variations and implementations may be realized.

Post Activity Module 138 may provide various actions for execution. Exemplary actions may include the following: memo on account, queue for credit review, queue for fraud review, contact customer, flag the account for suspected fraud, e.g., yellow flag, trigger an alert, etc.

Authorization Log 140 may store authorization history data and track decisions made by Decision Engine 120. For some transactions, Decision Engine 120 may access Authorization Log 140 to perform comparisons to attributes of current transactions. This may be particularly relevant to Velocity and Distance checks. Velocity may refer to the frequency of spend over a given period of time for similar transactions. For Velocity checks, an embodiment of the present invention may look for matches with current authorization. For example, multiple transactions of the same type at a high volume may indicate potential fraudulent behavior, such as purchasing ten plasma televisions within a 4 hour window. The rules may provide what types of matches to make, based on logic that was coded, e.g., match by merchant, MCC, POS entry mode, amount rage, etc. Distance may refer to the distance of the current transaction from the last transactions. For Distance checks, an embodiment of the present invention may return the sequence of zip codes for the requested time period. For example, an embodiment of the present invention may flag a transaction made in New York and a subsequent transaction made in California within a short time frame, such as 4 hours, for fraud based on the location and time between transactions.

Once a decision has been returned, various data, including logs, profiles, etc., may be updated through Authorization Controls 146.

According to another embodiment of the present invention, Decision Engine 120 may host a website or other electronic interface, where users may access data as well as provide data. For example, a financial institution, merchant and/or other entity may access information through an interface to view data, submit requests, provide data and/or perform other actions.

FIG. 2 is an exemplary flowchart illustrating a method for processing point of sale authorization requests, according to an embodiment of the present invention. At step 210, a POS authorization request may be received from a merchant or other entity. At step 212, profile data may be retrieved in response to the POS authorization request. At step 214, one or more rules may be applied. At step 216, one or more scoring algorithms may be applied. At step 218, an authorization response may be determined. At step 220, post decision activity may be performed. Also, feedback loop 222 may be implemented to further revise and refine profile data and/or other information. The order illustrated in FIG. 2 is merely exemplary. While the process of FIG. 2 illustrates certain steps performed in a particular order, it should be understood that the embodiments of the present invention may be practiced by adding one or more steps to the processes, omitting steps within the processes and/or altering the order in which one or more steps are performed. These steps will be described in greater detail below.

At step 210, a POS authorization request may be received from a merchant or other entity. The authorization request may be received from merchant location or other location for making a transaction.

At step 212, profile data may be retrieved in response to the POS authorization request. Profile data may include data associated with the customer, account and merchant. Other profile data may include geographic data indicating where the transaction is taking place as well as where the customer is currently located.

At step 214, one or more rules may be applied. Rules may include credit rules and fraud rules. An embodiment of the present invention may considers both credit and fraud factors in authorizing a transaction. For example, rules may identify segmentation data, such as customer spend data, transaction type, payment behavior, etc. While Apply Rules step 214 is illustrated in this exemplary diagram as occurring before Apply Scoring Algorithm step 216, step 214 can occur after, before or even concurrently with step 216. Other variations in the order of the steps illustrated in FIG. 2 may be realized.

At step 216, one or more scoring algorithms may be applied. The scoring algorithms may represent the risk involved in the transaction, such as fraud, credit default and/or other risk associated with a transaction. Other risk may include profitability, spend utilization, attrition and other types of risk.

At step 218, an authorization response may be determined. Based on the comprehensive data, an embodiment of the present invention may make a well decisioned determination for the POS authorization request. For example, profile data, including customer data, account data, merchant data and/or other data may considered. Risk assessment, including likelihood for fraud and/or credit default, may be considered in how to authorize a transaction. Other external sources of data may also be involved in determining POS authorization.

At step 220, post decision activity may be performed. Additional research and reporting may be performed, for example. In addition, the output may be considered in revising the rules and algorithms discussed above. A feedback loop may be implemented at step 222. For example, the customer's profile may be updated. If the customer is not fitting a certain profile or model, a customer contact may be initiated to arbitrate a questionable transaction. Based on the customer feedback, the customer's profile may be updated. According to another example, a customer questionnaire may be forwarded or requested to gather more accurate information.

While the exemplary embodiments illustrated herein may show the various embodiments of the invention (or portions thereof) collocated, it is to be appreciated that the various components of the various embodiments may be located at distant portions of a distributed network, such as a local area network, a wide area network, a telecommunications network, an intranet and/or the Internet, or within a dedicated object handling system. Thus, it should be appreciated that the components of the various embodiments may be combined into one or more devices or collocated on a particular node of a distributed network, such as a telecommunications network, for example. As will be appreciated from the following description, and for reasons of computational efficiency, the components of the various embodiments may be arranged at any location within a distributed network without affecting the operation of the respective system.

Data and information maintained by Decision Engine 120 may be stored and cataloged in Database 142 which may comprise or interface with a searchable database. Database 142 may comprise, include or interface to a relational database. Other databases, such as a query format database, a Standard Query Language (SQL) format database, a storage area network (SAN), or another similar data storage device, query format, platform or resource may be used. Database 142 may comprise a single database or a collection of databases, dedicated or otherwise. In one embodiment, Database 142 may store or cooperate with other databases to store the various data and information described herein. In some embodiments, Database 142 may comprise a file management system, program or application for storing and maintaining data and information used or generated by the various features and functions of the systems and methods described herein. In some embodiments, Database 142 may store, maintain and permit access to customer information, transaction information, account information, and general information used to process transactions as described herein. In some embodiments, Database 142 is connected directly to Decision Engine 120, which, in some embodiments, it is accessible through a network, such as communication network, for example.

Communications network may be comprised of, or may interface to any one or more of, the Internet, an intranet, a Personal Area Network (PAN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital T1, T3, E1 or E3 line, a Digital Data Service (DDS) connection, a Digital Subscriber Line (DSL) connection, an Ethernet connection, an Integrated Services Digital Network (ISDN) line, a dial-up port such as a V.90, a V.34 or a V.34bis analog modem connection, a cable modem, an Asynchronous Transfer Mode (ATM) connection, a Fiber Distributed Data Interface (FDDI) connection, or a Copper Distributed Data Interface (CDDI) connection.

Communications network may also comprise, include or interface to any one or more of a Wireless Application Protocol (WAP) link, a General Packet Radio Service (GPRS) link, a Global System for Mobile Communication (GSM) link, a Code Division Multiple Access (CDMA) link or a Time Division Multiple Access (TDMA) link such as a cellular phone channel, a Global Positioning System (GPS) link, a cellular digital packet data (CDPD) link, a Research in Motion, Limited (RIM) duplex paging type device, a Bluetooth radio link, or an IEEE 802.11-based radio frequency link. Communications network 107 may further comprise, include or interface to any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fibre Channel connection, an infrared (IrDA) port, a Small Computer Systems Interface (SCSI) connection, a Universal Serial Bus (USB) connection or another wired or wireless, digital or analog interface or connection.

In some embodiments, communication network may comprise a satellite communications network, such as a direct broadcast communication system (DBS) having the requisite number of dishes, satellites and transmitter/receiver boxes, for example. Communications network may also comprise a telephone communications network, such as the Public Switched Telephone Network (PSTN). In another embodiment, communication network 120 may comprise a Personal Branch Exchange (PBX), which may further connect to the PSTN.

In some embodiments, Decision Engine 120 may include any terminal (e.g., a typical home or personal computer system, telephone, personal digital assistant (PDA) or other like device) whereby a user may interact with a network, such as communications network that is responsible for transmitting and delivering data and information used by the various systems and methods described herein. Decision Engine 120 may include, for instance, a personal or laptop computer, a telephone, or PDA. Decision Engine 120 may include a microprocessor, a microcontroller or other general or special purpose device operating under programmed control. Decision Engine 120 may further include an electronic memory such as a random access memory (RAM) or electronically programmable read only memory (EPROM), a storage such as a hard drive, a CDROM or a rewritable CDROM or another magnetic, optical or other media, and other associated components connected over an electronic bus, as will be appreciated by persons skilled in the art. Decision Engine 120 may be equipped with an integral or connectable cathode ray tube (CRT), a liquid crystal display (LCD), electroluminescent display, a light emitting diode (LED) or another display screen, panel or device for viewing and manipulating files, data and other resources, for instance using a graphical user interface (GUI) or a command line interface (CLI). Decision Engine 120 may also include a network-enabled appliance, a browser-equipped or other network-enabled cellular telephone, or another TCP/IP client or other device.

As described above, FIG. 1 shows embodiments of a system of the invention. The system of the invention or portions of the system of the invention may be in the form of a “processing machine,” such as a general purpose computer, for example. As used herein, the term “processing machine” is to be understood to include at least one processor that uses at least one memory. The at least one memory stores a set of instructions. The instructions may be either permanently or temporarily stored in the memory or memories of the processing machine. The processor executes the instructions that are stored in the memory or memories in order to process data. The set of instructions may include various instructions that perform a particular task or tasks, such as those tasks described above in the flowcharts. Such a set of instructions for performing a particular task may be characterized as a program, software program, or simply software.

As noted above, the processing machine executes the instructions that are stored in the memory or memories to process data. This processing of data may be in response to commands by a user or users of the processing machine, in response to previous processing, in response to a request by another processing machine and/or any other input, for example. As described herein, a module performing functionality may comprise a processor and vice-versa.

As noted above, the processing machine used to implement the invention may be a general purpose computer. However, the processing machine described above may also utilize any of a wide variety of other technologies including a special purpose computer, a computer system including a microcomputer, mini-computer or mainframe for example, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, a CSIC (Customer Specific Integrated Circuit) or ASIC (Application Specific Integrated Circuit) or other integrated circuit, a logic circuit, a digital signal processor, a programmable logic device such as a FPGA, PLD, PLA or PAL, or any other device or arrangement of devices that is capable of implementing the steps of the process of the invention.

It is appreciated that in order to practice the method of the invention as described above, it is not necessary that the processors and/or the memories of the processing machine be physically located in the same geographical place. That is, each of the processors and the memories used in the invention may be located in geographically distinct locations and connected so as to communicate in any suitable manner. Additionally, it is appreciated that each of the processor and/or the memory may be composed of different physical pieces of equipment. Accordingly, it is not necessary that the processor be one single piece of equipment in one location and that the memory be another single piece of equipment in another location. That is, it is contemplated that the processor may be two pieces of equipment in two different physical locations. The two distinct pieces of equipment may be connected in any suitable manner. Additionally, the memory may include two or more portions of memory in two or more physical locations.

To explain further, processing as described above is performed by various components and various memories. However, it is appreciated that the processing performed by two distinct components as described above may, in accordance with a further embodiment of the invention, be performed by a single component. Further, the processing performed by one distinct component as described above may be performed by two distinct components. In a similar manner, the memory storage performed by two distinct memory portions as described above may, in accordance with a further embodiment of the invention, be performed by a single memory portion. Further, the memory storage performed by one distinct memory portion as described above may be performed by two memory portions.

Further, various technologies may be used to provide communication between the various processors and/or memories, as well as to allow the processors and/or the memories of the invention to communicate with any other entity; e.g., so as to obtain further instructions or to access and use remote memory stores, for example. Such technologies used to provide such communication might include a network, the Internet, Intranet, Extranet, LAN, an Ethernet, or any client server system that provides communication, for example. Such communications technologies may use any suitable protocol such as TCP/IP, UDP, or OSI, for example.

As described above, a set of instructions is used in the processing of the invention. The set of instructions may be in the form of a program or software. The software may be in the form of system software or application software, for example. The software might also be in the form of a collection of separate programs, a program module within a larger program, or a portion of a program module, for example The software used might also include modular programming in the form of object oriented programming. The software tells the processing machine what to do with the data being processed.

Further, it is appreciated that the instructions or set of instructions used in the implementation and operation of the invention may be in a suitable form such that the processing machine may read the instructions. For example, the instructions that form a program may be in the form of a suitable programming language, which is converted to machine language or object code to allow the processor or processors to read the instructions. That is, written lines of programming code or source code, in a particular programming language, are converted to machine language using a compiler, assembler or interpreter. The machine language is binary coded machine instructions that are specific to a particular type of processing machine, i.e., to a particular type of computer, for example. The computer understands the machine language.

Any suitable programming language may be used in accordance with the various embodiments of the invention. Illustratively, the programming language used may include assembly language, Ada, APL, Basic, C, C++, COBOL, dBase, Forth, Fortran, Java, Modula-2, Pascal, Prolog, ROM Visual Basic, and/or JavaScript, for example. Further, it is not necessary that a single type of instructions or single programming language be utilized in conjunction with the operation of the system and method of the invention. Rather, any number of different programming languages may be utilized as is necessary or desirable.

Also, the instructions and/or data used in the practice of the invention may utilize any compression or encryption technique or algorithm, as may be desired. An encryption module might be used to encrypt data. Further, files or other data may be decrypted using a suitable decryption module, for example.

As described above, the invention may illustratively be embodied in the form of a processing machine, including a computer or computer system, for example, that includes at least one memory. It is to be appreciated that the set of instructions, i.e., the software for example, that enables the computer operating system to perform the operations described above may be contained on any of a wide variety of media or medium, as desired. Further, the data that is processed by the set of instructions might also be contained on any of a wide variety of media or medium. That is, the particular medium, i.e., the memory in the processing machine, utilized to hold the set of instructions and/or the data used in the invention may take on any of a variety of physical forms or transmissions, for example. Illustratively, the medium may be in the form of paper, paper transparencies, a compact disk, a DVD, an integrated circuit, a hard disk, a floppy disk, an optical disk, a magnetic tape, a RAM, a ROM, a PROM, a EPROM, a wire, a cable, a fiber, communications channel, a satellite transmissions or other remote transmission, as well as any other medium or source of data that may be read by the processors of the invention.

Further, the memory or memories used in the processing machine that implements the invention may be in any of a wide variety of forms to allow the memory to hold instructions, data, or other information, as is desired. Thus, the memory might be in the form of a database to hold data. The database might use any desired arrangement of files such as a flat file arrangement or a relational database arrangement, for example.

In the system and method of the invention, a variety of “user interfaces” may be utilized to allow a user to interface with the processing machine or machines that are used to implement the invention. As used herein, a user interface includes any hardware, software, or combination of hardware and software used by the processing machine that allows a user to interact with the processing machine. A user interface may be in the form of a dialogue screen for example. A user interface may also include any of a mouse, touch screen, keyboard, voice reader, voice recognizer, dialogue screen, menu box, list, checkbox, toggle switch, a pushbutton or any other device that allows a user to receive information regarding the operation of the processing machine as it processes a set of instructions and/or provide the processing machine with information. Accordingly, the user interface is any device that provides communication between a user and a processing machine. The information provided by the user to the processing machine through the user interface may be in the form of a command, a selection of data, or some other input, for example.

As discussed above, a user interface is utilized by the processing machine that performs a set of instructions such that the processing machine processes data for a user. The user interface is typically used by the processing machine for interacting with a user either to convey information or receive information from the user. However, it should be appreciated that in accordance with some embodiments of the system and method of the invention, it is not necessary that a human user actually interact with a user interface used by the processing machine of the invention. Rather, it is contemplated that the user interface of the invention might interact, i.e., convey and receive information, with another processing machine, rather than a human user. Accordingly, the other processing machine might be characterized as a user. Further, it is contemplated that a user interface utilized in the system and method of the invention may interact partially with another processing machine or processing machines, while also interacting partially with a human user.

Further, although the embodiments of the present inventions have been described herein in the context of a particular implementation in a particular environment for a particular purpose, those of ordinary skill in the art will recognize that its usefulness is not limited thereto and that the embodiments of the present inventions can be beneficially implemented in any number of environments for any number of purposes. Accordingly, the claims set forth below should be construed in view of the full breadth and spirit of the embodiments of the present inventions as disclosed herein.

Claims

1. An automated computer implemented method for determining authorization for a transaction based on a merchant profile, wherein the method is executed by a decision engine comprising one or more computer processors which communicates with a user via a communication network, the method comprising the steps of: receiving an authorization request for a transaction from a customer at a merchant location, via a communication network;accessing a customer profile associated with the customer, from a computer database containing customer profile data and merchant profile data wherein a customer profile is associated with a particular customer and wherein a merchant profile is associated with a particular merchant, wherein the merchant profile comprises a merchant behavior profile, a merchant type, and a geographic location of the merchant;accessing, from the computer database, a merchant profile associated with a merchant involved in the transaction;executing, with the decision engine, one or more rules to the authorization request wherein the one or more rules generate merchant segmentation data to identify potentially fraudulent activity;executing, with the decision engine, one or more scoring algorithms to the authorization request wherein the one or more scoring algorithms indicate an assessment of risk;performing, with the decision engine, a velocity check to the transaction wherein the velocity check refers to a frequency of spend over a period of time for similar transactions for the merchant;performing, with the decision engine, a distance check to the transaction wherein the distance check refers to a distance between a current transaction and a previous transaction;in response to the customer profile data, the merchant profile, the merchant segmentation data, the assessment of risk, the frequency of spend and the distance check, automatically determining, with the decision engine, an authorization response; andtransmitting the authorization response for the transaction via the communication network.

2. The method of claim 1, wherein the merchant location comprises an online website.

3. The method of claim 1, wherein the merchant profile comprises an intersection profile with a card profile to determine at which merchants the card has been used.

4. The method of claim 1, wherein the velocity check is applied to the same merchant.

5. The method of claim 1, further comprising the step of: applying a feedback loop to update the merchant profile.

6. The method of claim 1, wherein the merchant profile data comprises one or more fraud indicators.

7. The method of claim 1, wherein the one or more scoring algorithm comprises credit risk and fraud risk; wherein the fraud risk is based on one or more of fraud events and fraud trends.

8. The method of claim 1, wherein the one or more scoring algorithm comprises one or more of profitability, spend utilization and attrition.

9. The method of claim 1, wherein the authorization response comprises one or more of memo on account, queue for credit review, queue for fraud alert.

10. An automated computer implemented system for determining authorization for a transaction based on a merchant profile, the system comprising: a computer database containing customer profile data and merchant profile data wherein a customer profile is associated with a particular customer and wherein a merchant profile is associated with a particular merchant, wherein the merchant profile comprises a merchant behavior profile, a merchant type, and a geographic location of the merchant anda decision engine, which decision engine comprises one or more computer processors and is coupled to the computer database and programmed to:receive an authorization request for a transaction from a customer at a merchant location, via a communication network;access, from the computer database, a customer profile associated with the customer;access, from the computer database, a merchant profile associated with a merchant involved in the transaction;execute one or more rules to the authorization request wherein the one or more rules generate merchant segmentation data to identify potentially fraudulent activity;execute one or more scoring algorithms to the authorization request wherein the one or more scoring algorithms indicate an assessment of risk;perform a velocity check to the transaction wherein the velocity check refers to a frequency of spend over a period of time for similar transactions for the merchant;perform a distance check to the transaction wherein the distance check refers to a distance between a current transaction and a previous transaction;in response to the customer profile data, the merchant profile, the merchant segmentation data, the assessment of risk, the frequency of spend and the distance check, automatically determine an authorization response for the transaction, with the decision engine; andtransmit, using the communication network, the authorization response to the authorization request for the transaction.

11. The system of claim 8, wherein the merchant location comprises an online website.

12. The system of claim 8, wherein the merchant profile comprises an intersection profile with a card profile to determine at which merchants the card has been used.

13. The system of claim 8, wherein the velocity check is applied to the same merchant.

14. The system of claim 8, wherein the instructions operable to cause the one or more processors to perform operations further comprise: applying a feedback loop to update the merchant profile.

15. The system of claim 8, wherein the merchant profile data comprises one or more fraud indicators.

16. The system of claim 8, wherein the one or more scoring algorithm comprises credit risk and fraud risk; wherein the fraud risk is based on one or more of fraud events and fraud trends.