KR102189658B1 - Auditing system with historic sale deviation database - Google Patents

Abstract

A method, system and computer program product are provided for auditing transactions involving the sale of travel services by an indirect seller. The audit module receives data defining the transaction proposed by the indirect seller. The audit module compares the quoted price for the transaction with the correct price for the transaction to determine if there is a price difference. If there is a price difference, the audit module classifies the transaction and searches a business rule database maintained by the travel service provider for business rules related to the classification. The audit module also queries the historical sales deviation database to fetch the seller history data, and selects the relevant business rules with the best match for the seller history data. The audit module then decides whether to allow or block the transaction, issue an alert, or propose an Agency Debit Memo (ADM) based on the action defined by the business rule with the best match.

Description

Audit system with historical sales deviation database {AUDITING SYSTEM WITH HISTORIC SALE DEVIATION DATABASE}

FIELD OF THE INVENTION The present invention relates generally to computers and computer software, and more particularly to methods, systems, and computer program products for auditing transactions associated with the sale of travel services.

In the travel industry, airline tickets are often sold through indirect sellers such as a validating carrier or online travel agency. Indirect sellers will typically check for available flights that satisfy the traveler's itinerary, and if matching flights are found, they will book flights for the traveler. As part of this booking process, the indirect seller can collect payments from travelers for tickets. In order to bear the operating carrier's charges for providing transportation services, the indirect seller provides a portion of the collected payments to the operating carrier.

To ensure that indirect sellers sell tickets in accordance with the rules and restrictions related to the pricing of the ticket, these transactions may be audited from time to time. The audit can verify that the amounts of fees, taxes, and fees match appropriate rules and constraints with respect to the details of the ticket sold. Due to the size of the annual global revenue generated by the airline industry, even correcting the small differences across all tickets sold can significantly recover the revenue otherwise lost.

In cases where the auditor indicates that the indirect seller was not properly charged for the ticket, the auditing airline may attempt to repair the difference by issuing an Agency Debit Memo (ADM). However, creating and issuing an ADM can add significant administrative costs to the transaction. For this reason, airlines can tolerate small errors in pricing rather than issuing ADM to repair the gap. Thus, the cost of issuing an ADM can provide an opportunity for indirect sellers to price tickets, consistently, slightly below the correct price, without penalty. In other cases, indirect sellers could honestly violate the airline's pricing rules due to changes made to the ticket, causing the airline to issue an ADM, which could otherwise be avoided.

Accordingly, airlines and indirect sellers have improved systems, methods, and methods to audit transactions, reduce the number of ADMs, and repair differences to reduce costs associated with incorrect pricing of travel services. Have a need for computer program products.

In an embodiment of the present invention, a method of managing a transaction by a seller of a travel service is provided. The method includes receiving data that characterizes the transaction and includes a first price for a travel service to be provided by the service provider. The method further includes determining, based on the service provider's pricing rules, a second price for the travel service, and determining whether the first price matches the second price. In response to the first price matching the second price, the method permits the transaction, and in response to the first price not matching the second price, the method is based on the set of transactions that occurred prior to the transaction. , Decide the action.

In another embodiment of the present invention, an apparatus including a processor and a memory is provided. The memory includes program code, which, when executed by the processor, causes the device to receive data that characterizes the transaction and includes a first price for a travel service to be provided by the service provider. do. The program code further causes the device to determine a second price for the travel service based on the service provider's pricing rules, and to determine if the first price matches the second price. In response to the first price matching the second price, the program code causes the device to accept the transaction, and in response to the first price not matching the second price, the program code causes the device to , Based on the set of transactions that occurred prior to the transaction, an action is determined.

In another embodiment of the present invention, a computer program product is provided that includes a non-transitory computer-readable storage medium containing program code. The program code, when executed by the processor, is configured to cause the processor to receive data that characterizes the transaction and includes a first price for a travel service to be provided by the service provider. The program code further causes the processor to determine, based on the service provider's pricing rules, a second price for the travel service, and determine if the first price matches the second price. In response to the first price matching the second price, the program code causes the processor to accept the transaction, and in response to the first price not matching the second price, the program code causes the processor to , Based on the set of transactions that occurred prior to the transaction, an action is determined.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings that form a part of this specification and are incorporated herein illustrate various embodiments of the invention, and together with the general description of the invention given above, and the detailed description of the embodiments given below, embodiments of the invention Serves to explain them.
1 is a diagrammatic view of an exemplary operating environment including a plurality of computer systems communicating over a network.
Fig. 2 is a diagram of the exemplary computer system of Fig. 1;
FIG. 3 is a diagram of a block diagram representing an operating environment including an audit module, a historical sales deviation (HSD) database, and a business rules database, which may be provided by one or more of the computer systems in FIG. 1 .
Figure 4 is a diagram of a transaction table that can be maintained by the HSD database of Figure 3;
5 is a diagram of a business rule table that may be maintained by the business rule database of FIG. 3;
6 is a flow diagram illustrating a process that may be executed by the audit module of FIG. 3 to implement embodiments of the present invention.

Embodiments of the present invention may be implemented by a processing and database system such as a Global Distribution System (GDS). The processing and database system may facilitate interconnections between indirect sellers of airline tickets and a plurality of computer reservation systems each associated with a travel service provider. In the context of air travel, the processing and database system may be configured to allow travelers to book airline tickets and other travel services through indirect sales channels. These indirect sales channels may include issuing airlines and online travel agencies that sell tickets for travel services to be provided by the operating airline. Indirect sellers may receive payment from travelers for reserved tickets, and then compensate the operating airline for the cost of the travel services provided.

The processing and database system includes a database containing data related to previous transactions made by one or more of the indirect sellers, a database of airline specific business rules to handle transactions, and a business with the best match for the transaction. It may include an audit module that interacts with each of the databases and the pricing engine to determine rules. In response to receiving a request to issue a ticket, the audit module may determine if the pending transaction violates any pricing rules of the issuing airline. The determination of whether a transaction is properly priced may be made while the transaction is pending, or in response to a request by an indirect seller to check the pricing prior to booking a ticket. In case the transaction is not properly priced, the audit module can access a database of business rules, including business rules specific to the issuing airline. Business rules related to the transaction being evaluated may change depending on the classification of the transaction.

In cases where more than one business rule is related to a transaction, the audit module may access a database of historical information to retrieve data related to previous transactions that have been improperly priced. This data can eventually be used to determine which of the relevant business rules should be applied for pending transactions. After that, the audit module, to reject the transaction; To allow the seller to take corrective action by warning the seller that the transaction was improperly priced; To allow the ticket to be issued, set a flag in the issuing airline's accounting system, to notify the issuing airline that an ADM should be issued; Alternatively, selected business rules can be applied to ignore improper pricing and allow ticket issuance without taking any additional action. The audit module may also enable the indirect seller to verify that changes to the priced ticket comply with the issuing airline's pricing rules before requesting issuance of the ticket.

Referring now to FIG. 1, an operating environment 10 according to an embodiment of the present invention includes a Global Distribution System (GDS) 12, one or more airline systems 14, which communicate via a network 18. ), and one or more travel agency systems 16. The airline systems 14, respectively, are a Computer Reservation System (CRS) for each airline that allows the GDS 12 or travel agency systems 16 to book airline targets and pay for airline tickets. ) Or other billing systems. The airline systems 14 may also interact with each other directly or through the GDS 12 to enable the issuing airline to sell tickets for seats provided by the operating airline. Thereafter, the operating airline may bill the issuing airline for the services provided. In some cases, the issuing airline may provide the service, in which case the issuing airline will also be the operating airline. Network 18 may include one or more private or public networks (eg, the Internet) that enable the exchange of data.

GDS 12 enables travel agents, issuing airlines, or other indirect sellers to book reservations on one or more airline systems 14 through GDS 12, thereby allowing travel agency systems to It may be configured to facilitate communication between 16 and the airline systems 14. To this end, the GDS 12 can maintain links to each of the airline systems 14 via the network 18. These links will allow the GDS 12 to route reservations and reservation requests from the travel agency systems 16 or the airline systems 14 of the issuing airline to the corresponding airline systems 14 of the operating airline. I can. Thereby, airline systems 14 and travel agency systems 16 can book flights for multiple airlines via a single connection to GDS 12.

Referring now to FIG. 2, the GDS 12, airline systems 14, and travel agency systems 16 of the operating environment 10 are one or more computing devices, such as the exemplary computer 20. Or systems. The computer 20 may include a processor 22, a memory 24, a mass storage memory device 26, an input/output (I/O) interface 28, and a human machine interface (HMI) 30. have. Computer 20 may also be operatively coupled to one or more external resources 32 via I/O interface 28 or network 18. External resources may include computers, servers, databases, mass storage devices, peripheral devices, cloud-based network services, or any other suitable computer resource that may be used by computer 20, but It is not limited thereto.

The processor 22 includes microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, field programmable gate arrays, programmable logic devices, state machines, logic circuits, analog circuitry. Devices, digital circuits, or any other devices that manipulate signals (analog or digital) based on operational instructions stored in memory 24. The memory 24 is a read-only memory (ROM), random access memory (RAM), volatile memory, nonvolatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, or It may include a single memory device or multiple memory devices including, but not limited to, any other device capable of storing information. Mass storage memory device 26 may include data storage devices, such as a hard drive, an optical drive, a tape drive, a non-volatile solid state device, or any other device capable of storing information.

The processor 22 can operate under the control of the operating system 34 residing in the memory 24. The operating system 34 allows the computer program code implemented as one or more computer software applications, such as the application 36 residing in the memory 24, to have instructions executed by the processor 22. You can manage your resources. In an alternative embodiment, processor 22 may directly execute application 36, in which case, operating system 34 may be omitted. One or more data structures 38 may also reside in memory 24 and may be used by processor 22, operating system 34, or application 36 to store or manipulate data. I can.

The I/O interface 28 may provide a machine interface that operatively couples the processor 22 to an external resource 32 or other devices and systems such as a network 18. Thereby, the application 36 communicates via the I/O interface 28 to provide various features, functions, applications, processes, or modules, including embodiments of the present invention. By doing so, it is possible to work in cooperation with the external resource 32 or the network 18. Application 36 may also have program code executed by one or more external resources 32, or otherwise, signals provided by other systems or network components external to computer 20 Can depend on the s or functions. Indeed, given the nearly limitless possible hardware and software configurations, those skilled in the art will appreciate that embodiments of the present invention are distributed among multiple computers or other external resources, located outside the computer 20, or cloud computing services. It will be appreciated that applications provided by computing resources (hardware and software) provided as a service over the network 18, such as may be included.

The HMI 30 may be operatively coupled to the processor 22 of the computer 20 in a known manner to allow a user to interact directly with the computer 20. HMI 30 may include video or alphanumeric displays, a touch screen, a speaker, and any other suitable audio and visual indicators that may provide data to a user. HMI 30 also accepts input or commands from a user and can transmit input input to processor 22, an alphanumeric keyboard, pointing device, keypads, pushbuttons, control knobs, Input devices and control means such as microphones and the like may be included.

Database 40 may reside on mass storage memory device 26 and may be used to collect and organize data used by the various systems and modules described herein. The database 40 may include data and supporting data structures that store and organize data. In particular, the database 40 may be arranged in any database configuration or structure including, but not limited to, a relational database, a hierarchical database, a network database, or combinations thereof. The database management system may be provided by a computer software application executing as instructions on the processor 22. Such a database management system may be used to access information or data stored in database records in response to an inquiry. The query may be determined and executed dynamically, by the operating system 34, other applications 36, or one or more modules.

Referring now to FIG. 3, an exemplary operating environment 50 according to an embodiment of the present invention includes an audit module 52, a historical sales deviation (HSD) database 54, a reservation module 56, a rate engine ( 58), a CRS 60, a business rules database 62, and a ticketing module 64, each of which may be provided by a suitable computing system. For example, the audit module 52, the HSD database 54, the reservation module 56, and the rate engine 58 may be provided by the GDS 12, and the CRS 60 and the business rules database 62 It may be provided by one of the airline systems 14, and the ticketing module 64 may be provided by one of the travel agency systems 16.

Purchasing an airline ticket or other travel service may involve pricing, booking, and ticketing the travel service. For example, if the traveler is satisfied with the itinerary, the travel agent may price one or more tickets including the itinerary by interacting with the user interface provided by the ticketing module 64. In response to this interaction, the ticketing module 64 can send a pricing request to the fare engine 58, which, in turn, determines prices for one or more tickets, and Respond to the targeting module 64.

The travel agent may allow tickets to be automatically priced based on the price received from the fare engine 58. The travel agent may also manually enter a price for the ticket, which may allow the travel agent to adjust the price from the price returned by the fare engine 58. In either case, the travel agent can reserve a ticket by having the ticketing module 64 send a reservation request to the reservation module 56. Thereafter, the reservation module 56 may communicate with the CRS 60 to determine the availability of one or more flights identified in the reservation request. If seats are available for the requested flights, the reservation module 56 can book the flight, and the CRS 60 can reduce the inventory of the corresponding operating carrier to reflect the reservation. Thereafter, the reservation module 56 may send a reservation confirmation to the ticketing module 64, and the ticketing module 64, in turn, may issue a ticket to the traveler. The traveler's account (eg, credit card) can be billed at the time of ticket issuance.

During the transaction, the audit module 52 identifies one or more characteristics of the transaction, such as an audit amount representing the exact price P _C that should be charged for the ticket, and the quoted price for the ticket P _Q. You can receive the data you define. Such data may be received directly from the reservation module 56 or the rate engine 58. Data may also be received by an audit module 52 that monitors communications between the GDS 12, airline systems 14, and travel agency system 16. Pricing for the ticket may be determined, for example, in response to the reservation module 56 receiving the reservation request. The exact price P _C may be based on data associated with the ticket, such as a booking code, class of service, origin-destination city pair, date of travel, or any other suitable data characterizing the ticket. This data is based on whether tariffs, pricing rules, routing maps, class of service tables, tax information, etc., were properly implemented by indirect sellers to determine the quoted price (P _Q ) for the ticket. Can be used to determine. Pricing rules may include reservation conditions such as minimum stay or advance purchase, and may be specific for a class or city pair of service.

Referring now to FIG. 4, the HSD database 54 may be configured to maintain a plurality of previous transactions in one or more transaction tables, such as the exemplary transaction table 70. The transaction table 70 may include a plurality of rows each representing fraudulent transactions 72a to 72n. Fraudulent transactions may include previous transactions that violate one or more of the issuing airline's pricing rules. The transaction table 70 may also include a plurality of columns each defining transaction characteristics 74a-74m associated with fraudulent transactions 72a-72n. Transaction characteristics 74a to 74m are, for example, the time or date 74a of the transaction, the identity 74b of the agent that caused the transaction, the identity 74c of the office where the transaction occurred, and the difference V associated with the transaction ( 74d), the fare category 74e violated, and whether there was a tax violation (74m).

Each fraudulent transaction 72a-72n may represent a transaction in which a ticket was allowed to be issued despite the presence of a pricing rule violation or other fraudulent activity. The transaction table 70 includes two parts: an indirect seller profile including, for example, the identity of the travel agent, the identity of the ticketing office, and the date of the transaction; And the cause of the difference (V) (e.g., penalty, improperly priced fee, failure to add taxes, incorrect fees, etc.), the extent or amount of the difference (V), actual collection amount, theoretical collection amount, violated It may consist of data describing the scam, such as rate category (cat 31, etc.), whether there was a tax violation, the type of transaction (issue, refund, reissue, etc.), or any other suitable data. have.

The HSD database 54 may be configured to purge stale data from the database. For example, HSD database 54 retrieves fraudulent transactions 72a-72n from transaction table 70 when transactions exceed a certain age (e.g., transactions with dates older than one year). Can be deleted. HSD database 54 may also determine one or more fraud statistics based on transaction characteristics 74a-74m from a plurality of fraudulent transactions 72a-72n. For example, the HSD database includes: frequency of fraud; The most violated rule for one or more of a rate category, transaction type, or tax violation; And the cumulative difference can be determined. The frequency of fraud may be equal to the number of fraudulent transactions stored in the HSD database 54 with a difference (V) exceeding a defined difference range, and a date falling within a defined check period. The cumulative difference may be equal to the sum of all differences V in a defined check period for a defined combination of transaction classification or transaction characteristics 74a-74m. These statistics can be determined as needed, can be predetermined and stored in memory, or can be determined dynamically and stored in a cache.

Referring now to FIG. 5, the business rule database 62 may include one or more business rule tables, such as the exemplary business rule table 80. The business rule table 80 may include a plurality of rows 82a to 82n each defining a business rule, and a plurality of columns 84a to 84m each representing a rule parameter. Exemplary rule parameters include difference range 84a (e.g., V ≥ $ 10), type of transaction 84b (e.g., first issue, refund, reissue), violated rate category 84c (e.g., cat 31 Voluntary changes), tax violation indicator 84d (e.g., yes or no), check level 84e (e.g., agent, enterprise, or office) providing the user level at which differences will be checked and accumulated , Check period 84f (e.g., last month, last week), which defines the time period over which differences will be checked and accumulated, cumulative fraud range (84g), frequency of fraud defining the range or number of events of fraud during the check period ( 84h) (eg, the number of transactions for which the difference V exceeds the difference range 84a), and an action 84m to be taken if the business rules 82a-82n are enforced.

In determining the applicability of the business rule, if a particular parameter is not considered or is ignored, the corresponding table entry may include a symbol (eg, *) indicating this. Business rule parameters 84a to 84m can be defined by the issuing airline, the cause of the difference (e.g., penalty fee, tax, incorrect fee, etc.), the actual amount collected by the travel agent, and collected by the travel agent. Other parameters not shown in the business rules table 80, such as a theoretical quantity, or any other suitable business rule parameter. By allowing each airline to define and manage their own business rules database 62, each airline can define a set of business rules that are specific to their business needs. Thereby, embodiments of the present invention allow airlines to define their own business rules and actions for handling pending transactions, based on fraud and history.

Business rule parameters may be classified as transaction criteria, HSD criteria, HSD results, or decisions. Transaction criteria are: variance range 84a, transaction type 84b, violated rate category 84c, tax violation indicator 84d, date (not shown), agent identity (not shown), office identity (not shown). ), or any other business rule parameter associated with the transaction itself. The HSD criteria may include transaction criteria, as well as check level 84e and check period 84f parameters. HSD results may include cumulative fraud, frequency of fraud, or any other results determined by applying transaction criteria to transaction characteristics stored in HSD database 54. The decisions may include actions 84m to be taken in response to applying the business rules 82a-82n to the pending transaction.

In response to receiving a request to issue a ticket, the audit module 52 may query the business rules database 62. The inquiry may contain information related to a pending transaction, such as the result of an audit of the transaction. In response to the query, the business rules database 62 may retrieve one or more related business rules. For each of the relevant business rules, then, the audit module 52 may query the HSD database 54 for HSD criteria that match the relevant business rule. Thereafter, the audit module 52 or the HSD database 54 may determine the frequency and cumulative amount of fraud based on transactions that satisfy the HSD criteria of the relevant business rule being evaluated. Thereafter, the audit module can reapply the HSD results as new criteria to determine which of the relevant business rules should be applied for the transaction and to take the corresponding action. If the transaction is accepted, the audit module 52 may update the HSD database 54 with the new transaction data.

Referring now to FIG. 6, a flow diagram is presented illustrating a process 90 that may be performed by the audit module 52 in accordance with an embodiment of the present invention. At block 92, process 90 may receive a request to reserve a travel service, such as a flight. In response to receiving the request, process 90 may proceed to decision block 94 and determine if the quoted price for the ticket (P _Q ) matches the issuing airline's pricing rules. This determination may be based on whether the quoted price (P _Q ) matches the exact price (P _C ). Pricing rules can be identified by a rate-based code, and characteristics of the transaction, such as booking class, ticket purchase requirements (e.g., pre-purchase request, refundable, non-refundable, web-only). Rates, etc.), stay requirements, round trip requirements, flight origin requirements, connection requirements, seasonal requirements, day of the week requirements, one or more fare categories, flight restrictions, or fares. It may be subject to any other rules or airline policy that must be satisfied to be appropriate for it. There may be multiple rate criteria that can be used in each market, and each rate criterion covers multiple possible rates. Pricing rules can also vary between airlines.

If the quoted price (P _Q ) matches the airline pricing rules (“Yes” branch of decision block 94), then process 90 can proceed to block 96 and the ticket is issued without further action. Can be allowed. If the quoted price P _Q does not match the airline pricing rules (the “no” branch of decision block 94), the process 90 may proceed to block 98. In an embodiment of the present invention, the quoted price (P _Q ) is accurate, as long as the difference (V = P _Q -P _C ) is equal to or greater than a predetermined minimum threshold (e.g., V ≥ 0). It can be considered to match the price P _C.

At block 98, process 90 can classify pending transactions. The classification may be based, for example, on whether the specified set of transaction characteristics matches the specified set of business rule parameters 84a-84m. In an embodiment of the present invention, the classification may be defined by the difference range 84a, the type of transaction 84b, the violated rate category 84c, and the value of the tax violation indicator 84d. Those of skill in the art will appreciate that other transaction characteristics may be used to classify pending transactions, and that embodiments of the invention are not limited to classifying pending transactions based on any particular set of transaction characteristics. In response to classifying the pending transaction, the process 90 may proceed to block 100.

At block 100, process 90 may fetch rules related to a pending transaction based on the classification. To this end, process 90 may send an inquiry 102 to the issuing airline's business rules database 62. Query 102 may request business rules database 62 to identify business rules related to the classification of pending transactions. In response to receiving the inquiry, the business rules database 62 may select business rules matching the classification from the plurality of business rules 82a-82n. That is, the business rules database 62 includes parameters (e.g., 84a to 84d) that match the characteristics used to classify pending transactions (e.g., difference range, type of transaction, violated rate category, or tax). Each of the business rules 82a-82n with the presence of violation) can be selected. Thereafter, the business rules database 62 may send a response 104 to the process 90 including the relevant business rules. Thereafter, the process 90 may proceed to block 106.

At block 106, process 90 may fetch merchant history data from HSD database 54 by sending one or more queries 108 to HSD database 54. Queries 108 may define search criteria that cause HSD database 54 to filter database search results so that only fraudulent transactions that satisfy the search criteria are considered. Thereby, the search criteria may define a set of transactions including one or more of the fraudulent transactions stored in the HSD database 54, related to at least one of the business rules withdrawn from the business rules database 62. have. For example, one or more inquiries 108 may include data on all fraudulent transactions related to the office causing the HSD database 54 to generate the pending transaction, and the fraudulent process involving the agent generating the pending transaction. You can request to return only data about transactions, or only data involving a specific corporate entity. Search criteria can be defined by the business rules that apply, and will include the check period (e.g., last month) and check level (e.g., travel agency, ticketing office, travel agent, or corporate entity) for which data should be returned I can. Thereby, the output of the HSD database 54 may be configurable such that the data includes data related to the issuing airline. Examples of data returned by HSD database 54 may include the frequency of fraud and cumulative fraud in the check period defined by the business rule triggering one or more queries 108.

In an embodiment of the present invention, process 90 may send an inquiry 108 for each business rule returned at block 100. In response to receiving the queries 108, the HSD database 54 may determine all fraudulent transactions 72a through 72n that match the business rules 82a through 82n identified by each query 108. have. For example, the business rule may define a difference range "> $ 10", a transaction type of "Issue", a rate category of "CAT 31", a check level of "Agent", and a check period of "1 month". In response to receiving this exemplary business rule, the HSD database 54 may return all ticket issuances for the last month with a CAT 31 violation and a difference> $10 for the agent that caused the pending transaction. . The HSD database 54 may provide such data by sending data determined from matching transactions, or a response 110 containing matching transactions, to the process 90. The HSD database 54 may also filter the data, based on the identity of the issuing airline, so that only fraudulent transactions for the issuing airline are considered by the process 90.

In response to receiving the fraudulent transaction data from the HSD database 54, the process 90 may proceed to block 112, where the fraudulent transaction data is retrieved to identify a single business rule to apply for the pending transaction. It can be applied as new standards. To this end, process 90 may remove business rules received at block 100 with parameters that fail to match vendor data. For example, process 90 may determine a fraud metric for each business rule based on fraudulent transaction data withdrawn for a corresponding business. The fraud metric may include, for example, one or both of the frequency of fraud and the cumulative fraud for the business rule being evaluated. These decisions may be made in the HSD database 54, may be transmitted to the audit module 52, or may be determined by the audit module 52, based on data received from the HSD database 54. If the determined cumulative fraud or frequency of fraud does not match the corresponding parameters of the business rule, the business rule may be removed from consideration by process 90.

After applying the fraudulent transaction data, if there is more than one business rule matching the possible fraud, the process 90 may select the business rule with the “best match”. The best match may be determined based on the restrictiveness of the business rule, and which business rule parameters 84a-84m are considered by the business rule. To this end, the process 90 may assign a weight to each parameter of the rules being evaluated, and determine the best matching score for each business rule by summing the weights of each parameter considered by the rule. I can. Weights can be defined based on the relevance of the parameters to avoid generating the same weighted score for two separate business rules 82a-82n, and to reduce fraud.

For example, it may be determined that the difference range 84a is more relevant to determining whether a transaction should be accepted, than the frequency of fraud 84h, and that the frequency of fraud 84h is more relevant than the violated rate category 84c. . Under this exemplary scenario, the difference range 84a may be assigned a weight with a relatively high value (e.g. 4), and the fraud frequency 84h may be assigned a weight with an intermediate value (e.g. 2). In addition, the transaction 84b may be assigned a weight having a relatively low value (eg, 1). Business rules matching fraud and taking each of these three parameters into account will receive a weighted score of 4 + 2 + 1 = 7. In contrast, business rules that match fraud but consider only the first two parameters (differential range 84a and frequency of fraud 84h are considered, and the type of transaction 84b is ignored), 4 + 2 = It will have a weighted score of 6.

In the case where two or more business rules have the same best match score, process 90 may further narrow the results to a single business rule by selecting the most restrictive of the remaining business rules. To this end, process 90 can start with the highest weighted parameter and work downwards, comparing the remaining business rules, based on the values of the individual parameters. Returning to the example above, the process 90 can compare the difference range 84a of each of the remaining business rules. If one business rule has a more restrictive range of difference than any of the other remaining business rules (e.g., the business rule requires a higher value of V), the business rule is Can be selected to evaluate Other examples of limitations include a check level 84e of "agent" compared to "office", which may include several agents. Thus, one parameter can be considered more restrictive than the other, as the more restrictive parameter applies to fewer transactions.

After comparing the higher weighted parameter (e.g., difference range 84a), if two or more business rules are still emptied, then process 90 weights the next highest weighted to the remaining rules. Parameters (eg, frequency of fraud 84h). In this way, the process 90 may remove the business rules sequentially until one business rule that provides the best match for the seller's history is selected. Thereafter, process 90 may proceed to decision block 114 and begin the process of determining how to treat the pending transaction.

At decision block 114, the process 90 may determine whether the action parameter 84m of the selected business rule is “reject”. If the action parameter 84m is "Reject", the processor 90 may reject the transaction (the "Yes" branch of the decision block 114) and may proceed to block 116. At block 116, the process 90 may cause the reservation module 56 to reject issuing the proposed transaction, in which case the issuing airline will not issue a ticket for the travel service. If the action parameter 84m of the selected business rule is not "reject" (the "no" branch of decision block 114), the process 90 may proceed to decision block 118.

In decision block 118, process 90 may determine whether to issue an alert to the travel agent. If the action parameter 84m of the selected business rule is not "warning" (the "no" branch of decision block 118), then process 90 may proceed to decision block 120 without issuing a warning. If the action parameter 84m of the selected business rule is “warning” (“Yes” branch of decision block 118), then process 90 may issue a warning to the travel agent and proceed to block 122. I can. In response to process 90 issuing an alert, an alert may be displayed on the user interface of ticketing module 64 and may indicate that the quoted price P _Q is incorrect. The warning may also provide the travel agent an indication of why the quoted price P _Q is wrong. After that, the travel agent can check the estimated price (P _Q), or whether modifications can be determined or estimated prices (P _Q) issued by knowing that one is incorrect, the ADM can be received as a result.

At block 122, process 90 may determine whether the travel agent modifies the quoted price P _{Q in} response to receiving the alert. If the travel agent modifies the quoted price (P _Q ) (the "Yes" branch of decision block 120), the process 90 can return to decision block 94, and the modified price is the airline price You can decide if it matches the rules of your choice. If the travel agent confirms the issuance without modifying the quoted price P _Q (the “no” branch of decision block 120), the process 90 may proceed to decision block 120.

At decision block 120, the process 90 may determine whether the ADM should be offered to the issuing airline. If process 90 determines that an ADM should be proposed (the "Yes" branch of decision block 120), then process 90 may proceed to block 122 and before proceeding to block 124, ADM flags can be set in the issuing airline's accounting system. Process 90 may set the ADM flag, for example, by having GDS 12 send a message to airline system 14 of the issuing airline. The ADM flag may cause the accounting system to notify the operator that an ADM should be generated in response to receiving a settlement for a pending transaction. If process 90 determines that an ADM should not be proposed (the “no” branch of decision block 120), then process 90 may proceed to block 124.

At block 124, process 90 may update HSD database 54 before proceeding to block 96 and allowing the target to be issued. Updating the HSD database 54, for example, causes the HSD database 54 to add fraudulent transactions 72a-72n to a transaction table 70 that contains transaction characteristics 74a-74m for pending transactions. It may include sending a message from the audit module 52 to the HSD database 54 to add a. In this way, the process 90 may update the HSD database 54 whenever a ticket with a difference V is allowed to be issued.

In cases where the travel agent has changed the transactional stored ticket, has manually priced the ticket, or is re-funding the ticket, the travel agent will, before submitting the transaction, the quoted price for the ticket (P _Q ) is You may want to decide if it matches the pricing rules of To facilitate a price check prior to submitting a transaction, embodiments of the present invention may include a price check feature. The price check feature may cause the ticketing module 64 to provide a price check button or other suitable object on the user interface of the ticketing module 64. The price check button may enable the travel agent to initiate a price check by activating the price check button. In response to the price check button being activated, the audit module 52 can access the fare engine 58 and determine if the quoted price for the ticket (P _Q ) matches the issuing airline's pricing rules. . Thereafter, the audit module 52 may cause the ticketing module 64 to display a message indicating the results of the price check. Thereby, embodiments of the present invention may allow the travel agent to perform a price check at any time before requesting an issue, refund, or any other suitable transaction. Thereafter, the system will provide a warning to the travel agent if the proposed price violates the issuing airline's pricing rules, thereby allowing the travel agent to modify the transaction and avoid receiving the ADM. will be.

In general, routines executed to implement embodiments of the present invention, whether implemented as part of an operating system, or as a specific application, component, program, object, module, or sequence of instructions, or even a subset thereof. However, it may be referred to herein as “computer program code” or simply “program code”. The program code typically resides at various times in storage devices and in various memories in the computer, and when read and executed by one or more processors in the computer, causes the computer to implement the invention. Elements implementing various aspects of the examples and/or computer readable instructions that cause them to perform the operations necessary to perform the operations. Computer-readable program instructions for performing the operations of embodiments of the present invention may be, for example, object code or source code written in assembly language, or any combination of one or more programming languages.

The various program codes described herein can be identified based on the application it is implemented in certain embodiments of the present invention. However, it should be appreciated that any particular program nomenclature that follows is used for convenience only, and therefore, the invention should not be limited to use only in any particular application identified and/or implied by such nomenclature. In addition, there are generally an infinite number of ways in which computer programs can be organized into routines, procedures, methods, modules, objects, etc., as well as various software layers where program functions reside within a typical computer ( For example, given various ways that can be allocated between operating systems, libraries, APIs, applications, applets, etc.), embodiments of the present invention can be applied to the specific configuration and assignment of program functions described herein. It should be recognized that it is not limited.

Program code implemented in any of the applications/modules described herein may be distributed individually or collectively as a variety of different types of program product. In particular, the program code may be distributed using a computer-readable storage medium having computer-readable program instructions for causing a processor to perform aspects of the embodiments of the present invention.

Computer-readable storage media, which are non-transitory in nature, are volatile and non-volatile, implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data, and Removable and non-removable tangible media may be included. Computer-readable storage media include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid state memory technology, portable compact disc read-only memory (CD-ROM). only memory) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and that can be read by a computer. I can. Computer-readable storage media are essentially transient signals (e.g., radio waves or other radio wave electromagnetic waves, electromagnetic waves propagating through transmission media such as a waveguide, or electrical signals transmitted over a wire). Should not be interpreted. Computer-readable program instructions can be downloaded from a computer-readable storage medium to a computer, other type of programmable data processing apparatus, or other device, or can be downloaded to an external computer or external storage device over a network. .

Computer-readable program instructions stored in a computer-readable medium include the instructions stored in the computer-readable medium, functions, acts, and/or operations specified in flowcharts, flowcharts, and/or block diagrams. A computer, other types of programmable data processing apparatus, or other devices may be used to instruct them to function in a particular way to create an article of manufacture containing instructions that implement them. Computer program instructions may be provided to one or more processors of a general purpose computer, special purpose computer, or other programmable data processing device to create a machine, and thus executed through one or more processors. The instructions to perform cause a series of calculations to be performed to implement the functions, actions, and/or actions specified in flowcharts, flowcharts, and/or block diagrams.

In certain alternative embodiments, functions, actions, and/or actions specified in flowcharts, flow charts, and/or block diagrams may be reordered, consistent with embodiments of the present invention. , May be processed sequentially, and/or may be processed simultaneously. Moreover, any of the flow charts, flow charts, and/or block diagrams may include more or fewer blocks than those illustrated, consistent with embodiments of the present invention.

The terms used herein are for the purpose of describing specific embodiments only, and are not intended to limit the embodiments of the present invention. As used herein, the singular forms "a", "an" and "the" are intended to also include the plural forms unless the context clearly indicates otherwise. The terms “comprises” and/or “comprising”, as used herein, refer to the mentioned features, integers, steps, actions, elements, and It is further noted that/or specifies the existence of components, but does not preclude the presence or addition of one or more other features, integers, steps, actions, elements, components, and/or groups thereof. Will make sense. In addition, the terms "includes", "having", "has", "with", "comprised of", or variations thereof are described in detail. Or in the scope used in the claims, such terms are intended to be included in a manner analogous to the term "comprising".

The whole of the invention has been illustrated by the description of various embodiments, and although these embodiments have been described in considerable detail, Applicants do not intend to limit the scope of the appended claims to such details or in any way. Does not. Additional advantages and modifications will readily appear to those skilled in the art. Accordingly, the invention in its broader aspects is not limited to the specific details, typical apparatus and method, and illustrative examples, shown and described. Accordingly, deviations from such details may be made without departing from the scope or spirit of the applicant's general inventive concept.

Claims (20)

As a method of auditing transactions implemented through hardware,
Receiving, at a processor, data characterizing the transaction, the data including a first price for a travel service to be provided by a service provider;
Determining, by the processor, a second price for the travel service based on a pricing rule of the service provider;
Determining, by the processor, whether the first price matches the second price;
In response to the first price matching the second price, allowing, by the processor, the transaction;
In response to the first price not matching the second price, determining, by the processor, at least one cause of a difference between the first price and the second price;
Determining, by the processor, at least one weighted difference parameter for at least one cause of the difference;
Determining, by the processor, at least one action parameter based on at least one cause of the difference, the at least one weighted difference parameter, and a set of transactions that occurred prior to the transaction; And
Determining, by the processor, an action based on the at least one action parameter
How to audit a transaction that includes. The method of claim 1,
Determining the at least one weighted difference parameter comprises determining a fraud metric based on the set of transactions,
Determining the at least one action parameter includes determining a business rule matching the fraud metric,
Wherein the at least one action parameter is based on the business rule. The method of claim 2,
The at least one action parameter is to allow the transaction, to allow the transaction and to display a warning message to the seller of the travel service, to allow the transaction and to propose an Agency Debit Memo (ADM), or A method of auditing a transaction by refusing the transaction. The method of claim 2,
Sending a request for the fraud metric to a database containing the set of transactions;
Determining the fraud metric in the database based on the set of transactions; And
Receiving the fraud metric from the database
How to audit a transaction that includes more. The method of claim 2,
The set of transactions includes a plurality of previous transactions,
The fraud metric is the frequency of fraud, cumulative discrepancy, or the most violated rule of the plurality of previous transactions. The method of claim 5,
The set of transactions is defined by the identity of the seller of the travel service, the identity of the office associated with the transaction, a check period in which the set of transactions was performed, or a combination thereof. How to appreciate the deal that would be. The method of claim 1,
The set of transactions is stored in a database,
The above method,
Updating the database by adding the transaction to the set of transactions.
How to audit a transaction that would include more. The method of claim 7,
Wherein the transaction is added to the set of transactions in response to the transaction being allowed. The method of claim 1,
The determining of the at least one weighted difference parameter includes determining a first plurality of business rules related to the transaction, and a fraud metric for each of the first plurality of business rules based on the set of transactions. Including the step of determining,
The determining of the at least one action parameter may include selecting one of the first plurality of business rules based on the fraud metric of each business rule, and the at least one based on the selected business rule. A method of auditing a transaction comprising the step of defining one action parameter. The method of claim 9,
The step of determining the first plurality of business rules,
Determining a classification of the transaction based on the characteristics of the transaction; And
Selecting the first plurality of business rules from a second plurality of business rules based on the classification
How to audit transactions that would include. The method of claim 10,
The characteristic used to determine the classification of the transaction is the value of the difference between the first price and the second price, the type of the transaction, the fare category violated by the transaction, or by the transaction. How to audit a transaction that includes a violated tax. The method of claim 9,
Determining the at least one weighted difference parameter may include determining a difference range based on application of a business rule to the set of transactions, or violated based on application of a business rule to the set of transactions. How to audit a transaction involving determining a rate category. The method of claim 1,
The set of transactions includes a plurality of previous transactions stored in a first database,
The step of determining the at least one action parameter,
Determining a classification of the transaction based on the characteristics of the transaction;
Querying a second database for business rules related to the classification;
For each business rule returned by the second database, determining search criteria, and based on the search criteria, querying the first database for a first fraud metric;
Determining a match between the second fraud metric and the first fraud metric defined by each business rule; And
Determining a business rule with the best match between the first fraud metric and the second fraud metric.
Including,
The method of auditing a transaction wherein the at least one action parameter is defined by the business rule with the best match. As a device for auditing transactions,
Processor; And
Memory containing program code
Including,
The program code, when executed by the processor, causes the device to:
Receiving data characterizing the transaction, the data including a first price for a travel service to be provided by a service provider;
Determine a second price for the travel service based on the service provider's pricing rules;
Determine whether the first price matches the second price;
In response to the first price matching the second price, allowing the transaction;
In response to the first price not matching the second price, determining at least one cause of a difference between the first price and the second price;
Determine at least one weighted difference parameter for at least one cause of the difference;
Determine at least one action parameter based on at least one cause of the difference, the at least one weighted difference parameter, and a set of transactions that occurred prior to the transaction;
And determining an action based on the at least one action parameter. In the computer-readable non-transitory storage medium storing the program code,
The program code, when executed by a processor, causes the processor to:
Receiving data characterizing the transaction, the data including a first price for a travel service to be provided by the service provider;
Determine a second price for the travel service based on the service provider's pricing rules;
Determine whether the first price matches the second price;
In response to the first price matching the second price, allowing the transaction;
In response to the first price not matching the second price, determining at least one cause of a difference between the first price and the second price;
Determine at least one weighted difference parameter for at least one cause of the difference;
Determine at least one action parameter based on at least one cause of the difference, the at least one weighted difference parameter, and a set of transactions that occurred prior to the transaction;
Computer-readable non-transitory storage medium for determining an action based on the at least one action parameter. delete delete delete delete delete

Images