Patent Application
20150221025
The invention generally relates to computers and computer software and, in particular to methods, systems, and computer program products for determining a payment strategy in a merchant environment.
Airline merchants have a need to integrate different and complex types of solutions to validate customer payments, combat fraud, and enable fund collection while operating within regulations and standards across a complex and fragmented payment industry. Payment platforms may offer solutions for payment processing that can help improve conversion rates, ensure revenue protection, and reduce costs. Payment platforms may provide travel agencies and travel industry companies with the computing environment for processing all of the payment services for the airlines. The payment services generally cover payment fraud screening to detect risks of fraud associated to a payment request, payment authorization to evaluate whether sufficient funds are available for payment and to block funds when necessary, etc.
Airline merchants must select payment parameters, such as the methods of payment to accept, the payment processors and the payment acquirers to use, and the fraud management schemes or strategies to adopt. Decisions about these payment parameters may be based upon experience and/or based upon on commercial relationships, rather than a robust evaluation of the financial impact of each payment parameter representing a potential alternative choice. As a result, an airline merchant may select payment parameters that do not necessarily match its overall operating mode.
There is a need for methods, systems, and computer program products to determine a payment strategy in a merchant environment, such as an airline merchant environment.
Embodiments of the present invention are directed to systems, methods, and computer program products to determine a payment strategy in a merchant environment, such as an airline merchant environment. Consistent with embodiments of the invention, financial parameters, categories, and one or more payment items for each category are received. One or more alternatives are determined for each category. Each alternative includes at least one of the one or more payment items. Transactions are received for different combinations of the alternatives. Financial impacts are determined for each simulated transaction based on the financial parameters. Based on the financial impacts, one of the combinations of the alternatives is determined to be the payment strategy for the payment platform.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the invention and, together with a general description of the invention given above and the detailed description of the embodiments given below, serve to explain the embodiments of the invention.
Referring now to
For interface with a user or operator, the computer system 100 may include a user interface 126 incorporating one or more user input/output devices, e.g., a keyboard, a pointing device, a display, a printer, etc. Otherwise, data may be communicated to and from another computer or terminal (e.g., the airline systems 14, the payment platform 18) over a network interface 128 coupled to the communication network 24. The computer system 100 also may be in communication with one or more mass storage devices, which may be, for example, internal hard disk storage devices, external hard disk storage devices, external databases, storage area network devices, etc.
The computer system 100 typically operates under the control of an operating system 130 and executes or otherwise relies upon various computer software applications, components, programs, objects, modules, engines, data structures, etc., including for example, a payment strategy module 132. In general, the computer system 100 may be configured to interface with one or more users, such as an airline merchant, in association with payment services and, in particular, in association with the determination of a payment strategy.
The memory 124 of the computer system 100 may generally store one or more databases including, for example, a database 150. The database 150 may comprise data and supporting data structures that store and organize the data. In particular, the database 150 may be arranged with any database organization and/or structure including, but not limited to, a relational database, a hierarchical database, a network database, and/or combinations thereof. A database management system in the form of a computer software application executing as instructions on the processing unit of the computer system 100 may be used to access the information or data stored in records of the database 150 in response to a query.
Moreover, various applications, components, programs, objects, modules, engines etc. may also execute on one or more processors in another computer coupled to the computer system 100 via the communication network 24, e.g., in a distributed or client-server computing environment, whereby the processing required to implement the functions of a computer program may be allocated to multiple computers over a network. For example, some of the functionality described herein as being incorporated into the computer system 100 and/or modules of the computer system 100 may be implemented in one or more servers. Consistent with embodiments of the invention, the module 132 and/or other such modules, applications, and/or engines may be executing on one or more servers of the computer system 100, and the modules 132 may cause the processor 122 of the computer system 100 to perform operations consistent with embodiments of the invention.
With reference to
A user is prompted to specify payment parameters in the form of payment categories 302. For each payment category, the user is further prompted to provide payment alternatives in the form of payment items that represent selection alternatives. A set of payment rules may be specified by the user for each payment item in a payment category. The payment categories, payment items in each payment category, and/or the payment rules for each payment item may be communicated over the network 20 from one of the airline systems 14 to the computer system 100, which receives this information as data to apply in the determination of the payment strategy.
A set of payment combinations is determined by the computer system 100 that groups the payment categories and the payment items selected as alternatives for each payment category with associated payment rules (block 202). A set of transactions is simulated by the computer system 100 for a specific payment category (block 204). For each payment combination generated in block 202, the impact on each payment category of the payment combination is computed by the computer system 100 for each simulated transaction (block 206). In block 208, financial parameters are acquired by the computer system 100. In block 210, the computer system 100 uses the financial parameters to compute the net profit value (NPV) for each payment combination. In block 212, the NPV for the different payment combinations are compared by the computer system 100 to provide a total financial impact of each payment strategy alternative, thereby allowing providing a payment strategy recommendation to the user.
With reference to
The determination of payment strategy may be performed and accessed through a user interface either directly on the computer system 100 or from a remote server over the World Wide Web on the Internet via a Uniform Resource Locator (URL). The user interface may be configured similar to user interface 126 such that a user can enter the payment categories, select different payment categories from a proposed list of options, or chose the payment categories from a mixture of selections and voluntary inputs.
The payment items that are alternatives for each of the payment categories 302, 304, 306, 308 may be created and registered using an alternative registration component and, in each instance, payment items that represent alternatives for each specific payment category may be created by a sub-component of the registration component. The user may enter or select payment items from a plurality of available payment items in order to identify alternatives for each of the payment categories 302, 304, 306, 308 to the computer system 100. If the user is already operating with the computer system 100, any payment items already received and used by the payment platform may be tagged or labeled as ‘current context’ or ‘historical’, which is received at the computer system 100. The user interface may be configured to offer the user a specific delimited area to enter the historical items for each payment category and another specific delimited area to enter the other payment items. The user may optionally provide specific rules to the computer system 100 that may be applied to the payment items of one or more of the alternatives in each of the payment categories 302, 304, 306, 308. In an alternative embodiment, the specific rules may also be retrieved by the computer system 100 from a database that stores predefined rules and/or historical rules (e.g., database 150).
For example and as illustrated with a representative use case, the user may select from among the available MOPs to define various different payment alternatives 312 for category 302. The user may select a payment alternative 312 (i.e., MOP_Alt1) that includes a group of payment items (Visa, MasterCard). MasterCard, for example, may be tagged as in the payment alternative (MOP_Alt1) 312 as ‘historical’, which indicates that this particular MOP is already used by the user. The user may select another payment alternative 312 (i.e., MOP_Alt2) that includes a group of payment items (Visa, MasterCard, Amex). The user may select yet another payment alternative (MOP_Alt3) 312 that includes a group of payment items (Visa, MasterCard, Amex, PayPal).
One or more rules governing the methods of payment may be applied to restrict the ability to initiate on-line payments with one of the payment items according to, for example, country or geographic territory. As a specific example, a rule may specify that one of the payment items may be restricted to use only for transactions initiated in the United States. It is appreciated that any variant in the rules formulation may be devised from the context of the airline merchant.
The computer system 100 may apply the rules to determine the payment alternatives 312 for the payment strategy. As a specific example based on PayPal being restricted to only for transactions initiated in the United States, the MOP rules may be: A) if the country is ‘US’, then the set of MOPs available for selection is Visa, MasterCard, Amex, and PayPal; and B) for any country other than the ‘US’, then the set of MOPs available for selection is equal to Visa, MasterCard, and Amex. In particular, these MOP rules may be applied to the third alternative (MOP_Alt3) of category 302 discussed in the representative use case.
For the payment category 304, the user may select one or more alternatives 314 for the payment acquirer. In the representative embodiment, a single alternative (Bank_Alt1) 314 is created and registered for the payment acquirer that selects one financial institution or bank to handle all transactions. For purposes of the example and representative use case, the alternative (Bank_Alt1) 314 may comprise the historical payment acquirer for the airline merchant. One or more rules may be applied to account for limitations, such as geographical limitations, on the availability of different payment acquirers.
For the payment category 306, the user may select one or more alternatives 316 for the payment processor. In the example and representative use case, the user may create and register an alternative (PSP_Alt1) 316 to select a payment processor that is operatively in communication with the payment acquirer of the selected alternative (Bank_Alt1) 314. For purposes of illustration, the payment processor of the selected alternative (PSP_Alt1) 316 may be a historical payment processor for the airline merchant. The user may create and register another alternative (PSP_Alt2) 316 that includes a different payment processor that is not necessarily operatively in communication with the payment acquirer of the alternative (Bank_Alt1) 316. However, the user may want the different alternative (PSP_Alt2) 316 to be studied by the process determining the payment strategy. One or more rules may be applied to account for limitations, such as geographical limitations, on the availability of different payment processors.
The computer system 100 may be configured to validate that the particular payment processors entered by a user are valid payment processors to handle all the MOPs previously selected by the user, and to inform the user of any incompatibilities.
For the payment category 308 for transaction acceptance protocol, the user may select one or more alternatives 318 for transaction acceptance protocol. In the example and representative use case, the user may create and register an alternative (Fraud Mgt_Alt1) 318 for transaction acceptance protocol based on a fraud screening provider having rules based on transaction data leading to accept, manually review, or reject decisions. For purposes of illustration, the alternative (Fraud Mgt_Alt1) 318 for transaction acceptance protocol may include the historical transaction acceptance protocol used by the airline merchant. Another alternative (Fraud Mgt_Alt2) 318 for transaction acceptance protocol may be created (e.g., a transaction acceptance protocol based on the use of a 3D Secure authentication). The alternative (Fraud Mgt_Alt2) 318 for transaction acceptance protocol may be independent-channel secure authentication validation mode. One or more rules may be applied to account for limitations, such as geographical limitations, on the availability of different transaction acceptance protocols.
After all payment alternatives are created for the payment categories 302, 304, 306, 308, combinations 320 of the payment alternatives 312, 314, 316, 318 for the payment categories 302, 304, 306, 308 and rules are generated or determined by the computer system 100 to establish different sets of combinations and rules.
For example, the following representative combinations may be generated for the payment alternatives 312, 314, 316, 318 of the representative use case in
With reference to
A history or volume of past transactions is retrieved by the computer system 100 and used as a set of transactions for the simulations (block 402). The volume of historical transactions to be taken into consideration may be based on those transactions executed over a given time period (e.g., several months) and stored in a transactions database. The transactions database may be located at the computer system 100. In block 404, the volume of historical transactions corresponding to the ‘historical’ alternative (MOP_Alt1) 312 for category 302 (
In block 406, the computer system 100 may receive one of the other alternatives 312 belonging to the category 302 for MOP as the subject alternative to be simulated. For example, the alternative (MOP_Alt2) 312 may be selected and, thereby, another payment item 310 (i.e., Amex) is introduced in comparison with the payment items 310 of alternative (MOP_Alt1) 312. In block 408, the computer system 100 may receive an increase for the volume of transactions obtained by the alternative. The user may be prompted by the computer system 100 to select one of the other alternatives 312 as the subject alternative and prompted by the computer system 100 to define the increase for the volume of transactions. In the illustrative example, the user may select a +5% increase in the total volume of transactions, which provides a total volume of 105% (see Table 2).
In block 410, the computer system 100 may receive a reallocation of the volume of transactions among the different payment items. The user may be prompted by the computer system 100 to reallocate the volume of transactions. In the exemplary embodiment, as shown in Table 3, the user selects to have +10% of transactions for the new MOP payment item ‘Amex’, and to reduce the volume for the historical MOP items from 60% to 57% for Visa and from 40% to 38% for MasterCard (see Table 3).
In block 412, the computer system 100 may compare, for each transaction of the past volume of transactions, the historical allocation of transactions (Volume 1) to the reallocation of transactions (Volume 2) received by the computer system 100 from the user for the alternative.
In block 414, the computer system 100 executes a simulation routine on all transactions of the set of historical transactions. The simulation routine executed by the computer system 100 sets a probability for each of the payment items for MOP depending on the reallocation provided by the user and received by the computer system 100. For each payment item having a lower volume in the reallocation (Volume 2) than the volume in the original allocation (Volume 1), the process retains the historical transaction and puts it in the set of simulated transactions with a probability equal to Volume2/Volume1. For each payment item having a higher volume in the reallocation (Volume 1) than the volume in the original allocation (Volume 2), the historical transaction is retained and put into the set of simulated transactions, and then put again in the set of simulated transactions with a probability equal to (Volume2/Volume1−1).
In the illustrative example, each historical transaction is added to the set of simulated transactions with a modified probability. Specifically, the historical transactions with Visa as a MOP are added to the set of simulated transactions with a probability of 57%/60%, and the historical transactions with MasterCard as a MOP are added to the set of simulated transactions with a probability of 38%/40%.
In the illustrative example, each historical transaction is added to the set of simulated transaction with a modified probability, and is associated with a new MOP payment item. The modified probability is equal to p=Volume 2 for new MOPs/Volume 1 for all historical MOPs. If there are multiple new MOP payment items, then each of these added transactions has a new method of payment MOP(i) assigned to it with an individual probability equal to pi/p, where pi are the individual percentages of the different new MOP payment items.
In the illustrative example, the process flow cycles through all transactions in the historical set again and copies the transactions into the new simulated set of transactions with a probability of 10%, and changes the previously unidentified MOP (now with a probability of 10%/10%) in the simulation to read Amex.
Finally, in block 416, a set of simulated transactions is generated by the computer system 100 for the selected alternative 312.
Another illustrative example is given below for the process flow of generating another set of simulated transactions, specifically for the alternative (MOP_Alt3) 312 that includes Visa, MasterCard, Amex, PayPal and that has a rule defined as ‘PayPal is used for the US only’, using the computer system 100.
As previously described, after the computer system 100 retrieves the historical transactions, the user defines by how much the new alternative will increase the total sales volume of transactions. In the illustrative example, because a MOP rule is defined with respect to territories or countries, the user defines 5% for countries other than the United States and 10% for the United States. The user is then prompted to modify the historical transaction split to reflect a new transaction split with the new MOP (i.e., PayPal) for the different countries or regions. An exemplary splitting for countries other than the United States is given in Table 4, and an exemplary splitting for the United States is given in Table 5.
The user is then prompted to reallocate the volume of transactions among the payment items for MOP, as shown in Table 6 for countries other than the United States and in Table 7 for the United States.
Simulations are run by the computer system 100 for all transactions in the set of past or historical transactions with the inputs defined by the user and received at the computer system 100. The simulations use transaction probabilities depending upon the user's inputs for the existing MOP items in the historical alternative, and use other probabilities for the new MOP items added by the different alternative.
In the example, all transactions of the past set of transactions are simulated a probability of 63%/65% if the transaction is a Visa transaction and not transacted in the United States, a probability of 34%/35% if the transaction is a MasterCard transaction and not transacted in the United States, a probability of 52%/58% if the transaction is a Visa transaction and transacted in the United States, and a probability of 38%/42% if the transaction is a MasterCard transaction and transacted in the United States. The historical transactions are also added to the new simulated set of transactions with a probability of 8% for transactions outside of the United States (and assigned to Amex with the individual probability for Amex equal to 8%/8%), and with a probability of 20% (the sum of 12% for Amex and 8% for Paypal) for transactions in the United States (and assigned to Amex with the individual probability for Amex equal to 12%/20% and assigned to PayPal with the individual probability for PayPal equal to 8%/20%).
With reference to
For Combinations 1 and 2 of the illustrative example, all historical transactions are linked to Bank_Alt1 as the payment acquirer and PSP_Alt1 as the payment processor. Then, depending on the rules in FraudMgt_Alt1 that is alternative 318 for transaction acceptance protocol in Combinations 1 and 2, it is determined for each transaction whether the transaction should be accepted, rejected or denied. For Combination 3 of the illustrative example, all historical transactions are linked to Bank_Alt1 as the payment acquirer and PSP_Alt2 as the payment processor. Transaction FraudMgt_Alt2 applies as the alternative 318 for transaction acceptance protocol, which means in the illustrative example the acceptance decision will be 3D Secure.
With reference to
For example, the following financial parameters may be defined by the user and received at the computer system 100. One financial parameter received by the computer system 100 may be the implementation costs 604 for each payment combination. In the illustrative example, these costs could be defined by the user. Specifically, for the Combination 1, the implementation costs 604 are 0 because this is the historical combination; for the Combination 2, the implementation costs 604 are 0
because the payment provider is the same as in Combination 1; and for Combination 3, the implementation costs 604 are 100,000
because the payment provider changes along with the need to implement communication to the payment acquirer. The values herein defined are representative and should not be interpreted as fixed values, as well as for the currency which can be defined in different currencies such as, for example, dollars. Another financial parameter 606 may be the discount rate for company investments: e.g., 15%.
Another financial parameter 608 received by the computer system 100 may be the merchant fee rules based on bank and transaction information. For the illustrative example, the fee rules could be defined as a fee of 0.6% for a Visa or MasterCard transaction, a fee of 0.3% for a Visa or MasterCard transaction with 3D Secure validation, a fee of 2% for an Amex transaction, and a fee of 3% for a PayPal transaction.
Yet another financial parameter 610 received by the computer system 100 may be the revenue leakage rules of the payment processor. For the illustrative example, the revenue leakage rules may be defined as 0.3% for payment provider PSP_Alt1 and 0% for payment provider PSP_Alt2. Another financial parameter 612 received by the computer system 100 may be the payment processing fee rules. For the illustrative example, the payment processing fee rules may be 6 cents per transaction for payment provider PSP_Alt1 and 5 cents per transaction for payment provider PSP_Alt2. Another financial parameter 614 may be the fraud management inputs, which result in a fraud probability of a rejected transaction, e.g., 20% payment provider PSP_Alt1 and 5% payment provider PSP_Alt2, a chargeback penalty, e.g., 20 per chargeback, a cost of processing one chargeback, e.g., 5
, a cost of performing one manual review, e.g., 3
, a gross margin, e.g., 20% for all products, an abandonment rate, e.g., 50%, a false positives of manual review process, e.g., 20% and a false negatives of manual review process, e.g., 20%, a false positives of 3D Secure process, e.g., 2% and a false negatives of manual review process, e.g. 20% for all countries.
After inputting all the requested financial parameters, a plurality of historical financial inputs are retrieved by the computer system 100 (block 620). The historical financial inputs may be retrieved either with a total cost of merchant fees, revenue leakage and payment processing fees, and total cost of fraud, or with merchant fees, revenue leakage, payment processing fees, and total cost of fraud inputs.
With reference to
In block 708, a NPV is determined by the computer system 100 for the currently-selected payment combination. If additional payments combinations of the payment alternatives 312, 314, 316, 318 are to be analyzed, then the next payment combination is selected and control returns to block 704.
By way of example, for Combination 2 that includes MOP_Alt2 as the alternative 312 for method of payment, the impact on the annual gross margin is computed by summing the amount of the whole set of simulated transactions, comparing it to the amount of the historical transactions, and determining the gross margin. As a numerical example, an amount of the initial sales with the historical alternative of the airline merchant be equal to 200 MEUR (million Euros), with a 20/80 split between the United States and the rest of the world. For Combination2, the worldwide gain in annual volume is calculated to be 2.5%, which leads to an incremental increase of 10 MEUR in sales (i.e., total sales of 210 MEUR) and, therefore, to an incremental increase in gross margin of 2 MEUR.
The impact may also be determined for the merchant fee for each transaction. The cumulated historical and the cumulated new merchant fee amounts are calculated over all transactions in the historical and the new sets of transactions, and then subtracted. As a numerical example, a historical merchant fee of 0.6% (fee for Visa or MasterCard transaction without 3D Secure) may be applied over the 200 MEUR sales. This results in a 1.2 MEUR in total historical merchant fees. A new merchant fee of 0.6% may be applied for Visa and MasterCard transactions with a ratio of 95%/105% of new amounts and a new merchant fee of 2% for Amex transactions with a ratio of 5%/105% of new amounts. By assumption, the Amex transactions have the same average amount than the Visa and MasterCard transactions. The total new merchant fee is then determined by the computer system 100 as:
210 MEUR*0.6%*95%/105%+210M*2%*5%/105%=1.34 MEUR
Therefore, upon comparison of the new merchant fee for Combination 2 with the total historical merchant fee for Combination 1, the annual difference in merchant fees is equal to −0.14 MEUR.
The impact may also be determined by the computer system 100 for the payment processing fee. Similarly, the cumulated historical and cumulated new payment processing fees may be calculated over all transactions in the historical and the new sets of transactions, and then subtracted. As a numerical example, an amount of average transaction may be set equal to 200 EUR, and the historical set of transactions containing 1M transactions and the new one 1.05 MEUR. The historical cumulated payment processing fee is therefore equal to 1M*0.05=0.05 MEUR and the cumulated new payment processing fee is equal to:
1.05M*0.05=0.0525 MEUR.
Therefore, when the new payment processing fee for Combination 2 is compared with the historical payment processing fee for Combination 1, the annual difference in payment processing fees is equal to 0.0025 MEUR.
The impact may also be determined by the computer system 100 for the revenue leakage. Similarly, the cumulated historical and cumulated new revenue leakage may be calculated over all transactions in the historical and the new sets of transactions, and then subtracted. As a numerical example, the average revenue may be set equal to 0.3%. The historical revenue leakage for Combination 1 is equal to 200 MEUR*0.3%=0.6 MEUR and the new revenue leakage for Combination 2 is equal to 210 MEUR*0.3%=0.63 MEUR. Therefore, upon comparison of the historical and new revenue leakages, the annual difference in revenue leakage is equal to −0.03 MEUR.
Finally, the impact may also be determined by the computer system 100 for the total cost of fraud. Similarly, the cumulated historical and cumulated new total cost may be calculated over all transactions in the historical and the new sets of transactions, and then subtracted. As a numerical example, a total cost of fraud may be set to about 2% as the same fraud management strategy is used for Combinations 1 and 2. The historical total cost of fraud is equal to 200 MEUR*2%=4 MEUR for Combination 1 and the new total cost of fraud for Combination 2 is equal to 210 MEUR*2%=4.2 MEUR. Therefore, upon comparison of the historical and new total costs of fraud, the annual difference in the total cost of fraud is equal to −0.2 MEUR.
Then, the annual incremental impact ‘an_imp’ is determined as a sum of the individual impact components:
2 MEUR−0.14 MEUR−0.0025 MEUR−0.03 MEUR−0.2 MEUR=1.63 MEUR
The NPV is then computed, for example, over a given time period. For example, the NPV may be computed over five years as follow:
NPV(5years)=an_imp/d*(1−1/(1+d)5)−imp_cost
Because there the implementation costs are nil for this combination, the NPV is equal to:
1.63 MEUR/15%*(1−1/115%̂5)=5.46 MEUR
Similarly, the previous computations of impacts may be performed for an example based on Combination 2. For annual gross margin, a gain in annual volume of 5% outside the US is determined, which produces an incremental increase in sales of 200 MEUR*80%*5%=8 MEUR. For the United States, the gain in annual volume is determined to be 10%, which produces an incremental increase in sales of 200 MEUR*20%*10%=4 MEUR. Consequently, when the components are summed to create worldwide totals, the worldwide increase in sales for Combination 2 is determined to be 12 MEUR and the incremental increase in gross margin for Combination 2 is determined to be 2.4 MEUR.
With respect to the merchant fee for Combination 2, the new merchant fee may 0.6% for Visa and MasterCard with a ratio of 90%/110% of US amounts and 97%/105% of non-US amounts, the new merchant fee may be 2% for Amex transactions with ratios of 12%/110% of US amounts and 10%/105% of non-US amounts, and the new merchant fee may be 3% for PayPal transactions with ratio of 8%/110% of US amounts. The total new merchant fee is computed as:
210 MEUR*(0.3%*(20%*90%/110%+80%*97%/105%)+2%*(20%*12%/110%+80%*10%/105%)+3%*(20*8%/100%))=1.08 MEUR.
Therefore, when comparing the merchant fee for Combination 1 with the merchant fee for Combination 2, the annual difference in merchant fees is equal to 1.2 MEUR−1.08 MEUR=0.12 MEUR.
With respect to the payment processing fee for Combination 2, the cumulative payment processing fee is determined to be 212M/200*0.06=0.0636 MEUR. Therefore, when comparing the payment processing fee for Combination 1 with the payment processing fee for Combination 2, the annual difference in payment processing fees is equal to the difference:
0.05 MEUR−0.0636 MEUR=−0.0136 MEUR.
With respect to revenue leakage, the revenue leakage with the new payment processor is 0%. Therefore, the annual difference in revenue leakage is equal to 0.6 MEUR. With respect to the total cost of fraud, the total cost of fraud may be assumed to be about 3% for a 3D Secure strategy because a different fraud management strategy is used in Combination 2. The new total cost of fraud would be equal to 212 MEUR*3%=6.36 MEUR. Therefore, when comparing the total cost of fraud for Combination 1 with the total cost of fraud for Combination 2, the annual difference in total cost of fraud is equal to −2.36 MEUR.
Finally, the annual incremental impact ‘an_impact’ is equal to the sum of the individual impacts:
2.4 MEUR+0.12 MEUR−0.0136 MEUR+0.6 MEUR−2.36 MEUR=0.75 MEUR
Because the implementation costs are 100K for deploying the solution of this alternative, the 5-year NPV is computed as being equal to:
0.75 MEUR/15%*(1−1/115%̂5)=2.6 MEUR
For the previous example, the process would generate as the result that the payment combination based on Combination 2 is the optimized payment combination with a NPV of 5.46 MEUR compared to the NPV of 2.6 MEUR of the Combination 3, even if the sales increase is not as much as for Combination 3. Combination 3 is selected because it creates more merchant fees and a better total cost of fraud.
The program code embodied in any of the applications/modules described herein is capable of being individually or collectively distributed as a program product in a variety of different forms. In particular, the program code may be distributed using a computer readable media, which may include computer readable storage media and communication media. Computer readable storage media, which is inherently non-transitory, may include volatile and non-volatile, and removable and non-removable tangible media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. Computer readable storage media may further 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), 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 the desired information and which can be read by a computer. Communication media may embody computer readable instructions, data structures or other program modules. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above may also be included within the scope of computer readable media.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other types of programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions that implement the function/act specified in the block or blocks of the flowchart and/or block diagram.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or another device to cause a series of computations to be performed on the computer, the other processing apparatus, or the other device to produce a computer implemented process such that the executed instructions provide one or more processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the embodiments of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Furthermore, to the extent that the terms “includes”, “having”, “has”, “with”, “comprised of”, or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising.”
While all of the present invention has been illustrated by a description of various embodiments and while these embodiments have been described in considerable detail, it is not the intention of the Applicant to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. The invention in its broader aspects is therefore not limited to the specific details, representative apparatus and method, and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of the Applicant's general inventive concept.
