text:
This document describes tools capable of altering to which interchange categories credit-card transactions are assigned. In some embodiments, the tools receive parameters for interchange categories and transaction information for a client (e.g., one or more merchants) that has been charged interchange fees based on some of these categories. The parameters are utilized (e.g., by a credit card issuer) to determine to which interchange category a particular transaction will be assigned. The tools may determine, based on these parameters and the transaction information, how transactions may be changed to enable similar credit-card transactions to be assigned to a lower-cost interchange category.
1. One or more computer-readable storage media having computer-readable instructions therein that, when executed by a computing device, cause the computing device to perform acts comprising:
receiving a first interchange category, a first interchange category cost, a second interchange category, and a second interchange category cost;
receiving transaction details for a client, the transaction details indicating that a particular transaction has been assigned to the first interchange category and including transaction information used to assign the particular transaction to the first interchange category; determining, by the computing device, a change in the transaction information that is capable of causing the particular transaction to be assigned to the second interchange category, the second interchange category cost being lower than the first interchange category cost; and reporting the change in the transaction information to an entity associated with the client.
2. The one or more computer-readable storage media of
3. The one or more computer-readable storage media of
4. The one or more computer-readable storage media of
5. The one or more computer-readable storage media of
6. The one or more computer-readable storage media of
7. The one or more computer-readable storage media of
8. The one or more computer-readable storage media of
9. The one or more computer-readable storage media of
10. One or more computer-readable storage media having computer-readable instructions therein that, when executed by a computing device, cause the computing device to perform acts comprising:
receiving transaction details for a client, the transaction details indicating one or more transactions having been assigned to a first interchange category and transaction information used to assign the one or more transactions to the first interchange category; determining, by the computing device, a change in the transaction information that is capable of causing the one or more transactions to be assigned to a second interchange category, the second interchange category having a lower cost than the first interchange category; and reporting the change in the transaction information to an entity associated with the client.
11. The one or more computer-readable storage media of
12. The one or more computer-readable storage media of
13. The one or more computer-readable storage media of
14. The one or more computer-readable storage media of
calculating a second transaction fee that the client would have been charged to process the one or more transactions based on the one or more transactions being assigned to the second interchange category; and reporting a difference between the first transaction fee and the second transaction fee.
15. The one or more computer-readable storage media of
16. The one or more computer-readable storage media of
17. The one or more computer-readable storage media of
18. The one or more computer-readable storage media of
19. The one or more computer-readable storage media of
20. The one or more computer-readable storage media of
This application is a continuation of and claims priority to U.S. patent application Ser. No. 12/554,691, entitled "Altering Card-Issuer Interchange Categories," filed on Sep. 4, 2009, which in turn is a continuation of and claims priority to U.S. patent application Ser. No. 11/740,190, now issued as U.S. Pat. No. 7,603,312 and entitled "Altering Card-Issuer Interchange Categories," filed on Apr. 25, 2007, the disclosures of which are incorporated in their entirety by reference herein.
In many typical credit-card transactions, a consumer purchases a product or service from a merchant using a VISA�- or MasterCard�-branded credit card. To complete the transaction, the merchant receives an authorization from a third party, known as a "merchant processor," which is sponsored by a VISA�- or MasterCard�-member bank. Merchants typically select a merchant processor to install point-of-sale equipment, train the merchant's staff in the use of the equipment, access the credit-card network for authorizations, and process the merchant's credit-card transactions.
The merchant processor, through its sponsoring bank, reimburses the merchant for each transaction after deducting transaction fees. Within these transaction fees are the merchant processor's processing fee, the interchange fees paid to the issuer of the credit card, and the assessment fees that are paid to the credit-card association. The merchant processor submits the net transaction into the card association's settlement network in order to be reimbursed by the issuing bank. The VISA� and MasterCard� associations are responsible for building, operating, maintaining, authorizing, and providing the information required for the member banks to settle their net transaction volume. Each association receives an assessment fee from both the merchant processor's bank and the issuer's bank for each credit-card transaction processed through their respective network. The issuer in turn bills the consumer the full amount of the original charge.
Card issuers charge interchange fees based on interchange categories that each assigns to credit-card transactions. The card issuers, however, may assign each transaction to one of over 100 different interchange categories. Understanding these different interchange categories can be quite difficult for merchants, often resulting in merchants being overcharged or at the least not knowing how best to reduce these fees in the future. The potential savings merchants could enjoy can be substantial—card issuers currently charge merchants billions of dollars a year in interchange fees worldwide.
These interchange categories are difficult to understand in part because there are so many different kinds. Some are based on the merchant's retail industry status, some on the type of card presented for payment, some on the process used by the merchant to gain authorization for the transaction, some on the type of information received, and many on a combination of these factors. The interchange categories (and thus the rate charged) may depend, for example, on whether the consumer's and card's data is processed electronically from the magnetic strip on the back of the card, manually by the merchant based on the information set forth on the card, or manually by the merchant based on information provided by the consumer over the telephone. In short, the number and complexity of these categories make it difficult for a merchant to reduce its interchange-category fees.
Not only are the interchange categories themselves often difficult to understand, the effect of these interchange categories may be difficult to track because of the sheer number of transactions received by merchants; some merchants receive hundreds of thousands of transactions a month. Many merchants simply do not have the extraordinary manpower or expertise often needed to analyze these transactions to figure out how much they may save—even if they did understand how to change the categories assigned to their transactions.
Further still, merchant processors—the companies that have good information about interchange categories and their fees—often have no incentive to help merchants reduce these fees; most merchant processors make no more money by providing details about these complexities than not doing so and some may even lose money by providing these details.
This document describes tools capable of altering to which interchange categories credit-card transactions are assigned. In some embodiments, the tools receive parameters for interchange categories and transaction information for a client (e.g., one or more merchants) that has been charged interchange fees based on some of these categories. The parameters are utilized (e.g., by a credit card association) to determine to which interchange category a particular transaction will be assigned. The tools may determine, based on these parameters and the transaction information, how transactions may be changed to enable similar credit-card transactions to be assigned a lower-cost interchange category and the accompanying potential fee savings.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The term "tools," for instance, may refer to system(s), method(s), computer-readable instructions, and/or technique(s) as permitted by the context above and throughout the document.
Non-limiting and non-exhaustive embodiments are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.
The following document describes tools capable of altering to which interchange categories credit-card transactions are assigned and accompanying potential fee savings, as well as other capabilities. In some cases the tools determine ways in which to alter interchange categories by receiving parameters for interchange categories and determining lower-cost interchange categories available to a client if the client implements one or more transaction changes, such as gaining a customer's signature or entering additional information. In some embodiments, a client may include one or more merchants. While certain embodiments herein are discussed with reference to a merchant or merchants, this is not intended to be limiting, and the described tools may be implemented for any suitable entity without departing from the spirit and scope of the claimed embodiments.
The tools discussed herein may also receive information indicating, for a particular area of business, potential lower-cost interchange categories and, based on a client's currently-assigned interchange categories, determine which currently-assigned interchange categories may be replaced by these lower-cost interchange categories. In either case, the tools may determine and provide potential fee savings based on the lower-cost interchange categories being assigned instead of the current interchange categories. By so doing the tools may save clients significant amounts of money by helping them lower their interchange fees.
An environment in which the tools may enable these and other actions is set forth below in a section entitled Example Operating Environment. This section is followed by Storing Credit-Card Transaction Data, which describes one particular example in which the tools act to enable an interchange module to receive credit-card transaction data and perform other actions for a national bookstore chain. The next section, entitled Building and Adjusting Baseline Interchange Rates, continues the bookstore example in the context of building and adjusting a baseline interchange rate for the national bookstore chain. The next section, entitled Determining Ways in which to Alter Interchange Categories, continues the bookstore example in the context of determining ways in which to have a lower-cost interchange category assigned instead of a higher-cost interchange category, as well as the accompanying potential savings.
The following section also continues the bookstore example and determines a savings between an adjusted baseline interchange rate and a current rate; it is entitled Determining Card-Issuer Interchange-Fee Savings. The next section, entitled Auditing Interchange Categories, continues the example but from the Storing section, and describes ways in which the tools audit interchange categories assigned to credit-card transactions. A final section describes various other embodiments and manners in which the tools may act and is entitled Other Embodiments of the Tools. This overview, including these section titles and summaries, is provided for the reader's convenience and is not intended to limit the scope of the claims or the entitled sections.
Example Operating Environment
Before describing the tools in detail, the following discussion of an example operating environment is provided to assist the reader in understanding some ways in which various inventive aspects of the tools may be employed. The environment described below constitutes but one example and is not intended to limit application of the tools to any one particular operating environment. Other environments may be used without departing from the spirit and scope of the claimed subject matter.
The data sources may include text-formatted documents easily readable by humans (e.g., paper), websites, or accessible databases, to name a few. The data-entry entity is responsible for retrieving information from the data sources and storing it in the relational database. This entity may include a person reading information from a paper document or website and typing the information into an application through which information is stored in intermediate memory or directly into the relational database, an application using Application Program Interfaces (APIs) to access API-accessible databases or applications and store information, or a Bot (an Internet-searching data gatherer) capable of gleaning information from websites and other data sources over the Internet. This entity may store information automatically and/or without user interaction in many cases, such as when it includes an application using APIs or a Bot.
The relational database includes one or more databases in which data may be stored and from which data may be extracted, such as a SQL™, Oracle™, or IBM™ DB2 relational database.
The computing device includes one or more processor(s) 110 and computer-readable media 112. The computing device is shown with a server icon, though it may comprise one or multiple computing devices of various types. The processors are capable of accessing and/or executing the computer-readable media.
The computer-readable media includes or has access to a formatting module 114, an interchange module 116, a report generator module 118, a category module 120, and a category entity 122. Each of these modules and the category entity (except when the category entity is or includes non-software elements) may be integral or separate; they are shown separate to aid in describing functionality and actions of each, though this is not required.
In many cases credit-card transaction data is provided in a format or formats that are not easily readable by the interchange module or are not consistent. In these cases the formatting module may transform the information into one, easily-machine-usable format, often prior to loading it into the relational database. In one example case described in greater detail below, the formatting module includes an executable Extract, Transform, and Load (ETL) package. This ETL package may extract human-readable, text-formatted (e.g., pre-transformed) credit-card transaction data of one or multiple formats, transform this data into a format easily-usable by the interchange module, and load it into the rational database in a standardized format that may be used for computation.
The interchange module is capable of auditing and/or tracking reductions to interchange fees charged to merchants incident to those merchants accepting payments with credit cards. Note that the term "credit" includes credit, debit, and other accounting systems so long as they are processed by a credit or debit association (e.g., VISA� and MasterCard�). Also note that the term "card" applies to any medium or manner in which sales or purchases may be electronically transacted, such as a card having a magnetic strip, a card having circuitry, a credit account not having any physical element, or a key-faub that electromagnetically identifies an account. Ways in which the interchange module may audit and/or track fee reductions are developed in greater detail below.
The report generator module is capable of receiving information from the interchange module and the category module and providing reports on this information in human or computer-readable formats.
The category module is capable of determining ways in which to alter interchange categories assigned to credit-card transactions and accompanying potential fee savings, as well as providing information indicating its findings (e.g., to the report generator module). The category module may include, have access to, or interact with the category entity. As will be described in detail below, the category entity may perform some of the actions and functions of the category module and may be software (e.g., an application, applet, or other code), or a person, or a combination of both.
Various techniques described herein may be implemented via computer-executable instructions stored on computer-readable storage media. "Computer-readable storage media" include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. As used herein, computer-readable storage media of a computing device are configured to store information and thus do not include a signal bearing medium or other transitory media.
Storing Credit-Card Transaction Data
This section describes one particular example in which the tools act to store credit-card transaction data and enable the interchange module to receive this data. This example is an implementation of the tools but is not intended to limit the scope of the tools or the claimed embodiments.
The credit-card transaction data that the tools enable the interchange module to receive includes information about credit-card transactions (e.g., customers purchasing a product or service from a merchant using a credit card). This credit-card transaction data may include, for each purchase or groups of purchases, the purchase price, the date of the purchase or date that the purchase was batched by the merchant, a card-issuer interchange category, fee, or rate for the purchase, and through which credit-card association's network the purchase was made (e.g., VISA� or MasterCard�). The data may also indicate each purchase and its interchange category or groups of purchases by their interchange category, some of which are noted later in the discussion.
Parameters used to determine the category may also be included in the credit-card transaction data or determined based on information in the credit-card transaction data. These parameters may be divided, conceptually, into four categories: 1) a merchant's area of business; 2) information received for a transaction; 3) how information is received for a transaction; and 4) type of card used in a transaction. These parameters are described in greater detail below.
Having described the credit-card transaction data generally, the example turns to
At arrow 2-1 in
The example national bookstore chain is assumed to have, for each bookstore, a merchant at its coffee shop, merchants at its check-out line, and a merchant at its service counter. This national bookstore also has merchants accessible through the Internet for website purchases. Assume that the national bookstore has 200 stores and 2,000 merchants. Each of the merchants may have hundreds or thousands of credit-card transaction per billing period, amounting to 800,000 to 8,000,000 credit-card transactions per billing period (e.g., a calendar month). As this number suggests, it is difficult for clients to keep track of all credit-card transactions in a billing period by reading merchant-processor statements on websites, on paper, or in human-readable text formats.
Consider the following example merchant-processor statement in human-readable text format. This processor statement is presented at the merchant processor's website 102 w of
At arrow 2-2, the data-entry entity stores the credit-card transaction data into intermediate storage 204 in the human-readable text format. The data stored in this example is human-readable text and likely differs from a format of some other merchant or client or is not an easily-machine-usable format. The tools proceed to arrow 2-3 to address this issue.
At arrow 2-3, formatting module 114 extracts the text-format credit-card transaction data for the thousands of merchants of the national bookstore chain using an Extract portion of an Extract, Transform, and Load (ETL) process. The tools execute a formatting ETL package 206, shown included in the formatting module of
At arrow 2-4, the formatting module transforms the text-format credit card transaction data into an easily-machine-usable format for the thousands of merchants and using a Transform portion of the ETL process. This transformation is shown with arrow 2-4.
At arrow 2-5, the formatting module loads the credit-card transaction data in the easily-machine-usable format into the relational database. It loads the credit-card transaction data in this easily-machine-usable format for the thousands of merchants using a Load portion of the ETL process. For the one example merchant above, the formatting module stores its data into table 208 of the rational database. The formatting module also associates the merchant identifiers (here the "Merchant's Identification Number") in table 208 with the appropriate credit-card transaction data. The formatting module may also or instead associate the credit-card transaction data with internal database record numbers.
At this point in the process, credit-card transaction data is stored in the relational database in a format that is easily usable and consistent. By so doing, interchange module 116 may use the data to audit, track fee reductions, or otherwise use information about interchange categories for credit-card transactions. Examples of how the interchange module may do so are described below and include building a baseline card-issuer interchange rate and adjusting that rate, auditing card-issuer interchange fees, and tracking reductions in those fees. Category module 120 may use the data to determine potential fee savings if the interchange categories assigned are replaced by lower-cost interchange categories.
Examples of how the category module may act are described after the following section and also include analyzing categories and their parameters to determine ways in which to alter which category will be assigned in the future to similar transactions. Similar transactions are those transactions that would be assigned the same interchange category were a parameter change not made. Thus, a current transaction where a card was swiped but no signature is received is similar to a future transaction where a card is swiped and a signature is received, so long as if the future transaction did not have a signature it would have been assigned the same category. The parameter change here is addition of the signature.
Building and Adjusting Baseline Interchange Rates
This section continues the above example in the context of credit-card transaction data being made available to interchange module 116 to build and adjust a baseline interchange rate for the above-described national bookstore chain. In later sections the transaction data made available to the interchange module will be used for other purposes, such as monthly auditing or determining actual or potential savings.
In this section the tools start by building, automatically and without user interaction, a baseline interchange rate for the bookstore client based on a twelve-month history of credit-card transaction data for the bookstore's 2,000 merchants. The interchange module is enabled to extract this historical data by the tools performing the actions of
The credit-card transaction data received is in an easily-machine-usable form and includes card-issuer interchange fees, card-issuer interchange categories assigned, dollar volumes, and numbers of transactions to which card-issuer interchange categories are assigned by a merchant processor. This data is for each merchant and for each billing cycle of the historic period, i.e., twelve historic merchant-processor statements of each particular merchant for all of the bookstore's merchants over the historical twelve-month period.
Specifically, at arrow 3-1 in
At arrow 3-2, the interchange module adds up all the fees and dollar volumes for each merchant over the twelve-month period. The interchange module then does this again and again for every merchant and then adds these together. By so doing, the interchange module determines the client's total fees and dollar volume on which the fees were based.
At arrow 3-3, the interchange module divides the total fees by this dollar volume to provide a baseline card-issuer interchange rate for the historical twelve-month period for the bookstore.
At arrow 3-4, the interchange module loads the baseline card-issuer interchange rate into relational database 106. The interchange module performs the actions of arrows 3-1 to 3-4 using baseline ETL package 302, shown included in interchange module 116 in
After building the baseline, the tools proceed to adjust the baseline in the following example manner.
At arrow 3-5, the interchange module determines the dollar volume on which each card-issuer interchange category was assigned for all credit-card transactions for all of the bookstore's 2,000 merchants during the historic period. The categories assigned may be tracked as part of arrows 3-1 to 3-3 or separately, as is done here. Here the interchange module extracts, from the historic credit-card transaction data for the bookstore's merchants, the interchange categories assigned, the dollar volumes, and the number of transactions for each of the interchange categories.
Consider a portion of the example merchant-processor statement provided above:
In this case the interchange module determines that 461 credit-card transactions totaling $27,404.65 were assigned a "VISA� CPS RETAIL" card-issuer interchange category for one merchant for one billing cycle. The interchange module does this over and over for each category and each merchant and each billing cycle in the historic period. Assume, for example, that the interchange module determines that 800,000 transactions totaling $50,000,000 were assigned a "VISA� CPS RETAIL" category for the bookstore during the twelve-month history.
At arrow 3-6, the interchange module receives current card-issuer interchange rates for each of the categories assigned to a credit-card transaction. The module receives this by extracting it from the relational database into which it was stored by data-entry entity 104 either automatically or by manual user entry.
At arrow 3-7, the interchange module determines if any of the assigned category's rates have changed. Assume that the "VISA� CPS RETAIL" rate, which during the historic period was 1.54% of each sale plus $0.10 per sale, is now 1.55% of each sale plus $0.11 per sale. For simplicity, assume for this portion of the example that no other category's rate has changed since or during the twelve-month historical period (which is unlikely). The interchange module determines that the "VISA� CPS RETAIL" rate changed based on its old rate (which was found in the credit-card transaction data in the merchant-processor statement but could be found in other ways) compared to the new rate.
At arrow 3-8, the interchange module determines the rate change—here 0.01% of each sale and $0.01 per sale.
At arrow 3-9, the interchange module determines a fee difference over the historical period sufficient to reflect the rate change. This rate change reflects what the baseline rate would have been had the new rate been charged throughout the historic period. The interchange module multiplies the rate change by the dollar volume and number of transactions.
The "VISA� CPS RETAIL" category had 800,000 transactions totaling $50,000,000, so the fee difference is:
At arrow 3-10, the interchange module adds this fee to the total fee for all credit-card transactions for the bookstore during the historical period. Here assume the total fee was $15,000,000. Thus, the adjusted fee over the baseline historical period would be $15,013,000.
At arrow 3-11, the interchange module divides the adjusted fee of $15,013,000 by the total dollar volume for the bookstore over the historical period (e.g., $750,000,000). This provides an adjusted baseline card-issuer interchange rate. If the fee based on the adjusted rate was $15,000,000 divided by $750,000,000, and thus 2.00%, the adjusted baseline rate is 2.00173333%.
At arrow 3-12, the interchange module stores the adjusted baseline rate in relational database 106 of
Determining Ways in which to Alter Interchange Categories
This section continues the above example in the context of determining ways in which to alter an interchange category assigned, such as the interchange category assigned in a prior merchant-processor statement for the example bookstore. Current or historic statements may be audited and analyzed, though this particular example focuses on a historic statement to describe an example way in which the tools analyze interchange categories to reduce interchange category fees charged now and in future statements.
For this portion of the ongoing example, assume that some of the bookstore's merchants have different areas of business. Assume that one merchant is a merchant through which a university bookstore receives and records transactions for textbook sales either in person or over the phone. This university merchant, even though associated with the national bookstore chain, qualifies as operating in an educational area of business, which affects the interchange categories that may be assigned to its transactions.
Prior to analyzing credit-card transaction data, however, the tools act to learn about interchange categories and their parameters. One example way in which the tools may do so is described below using category entity 122 and category module 120.
At arrow 4-1 in
The following interchange categories, along with their parameters, are currently used by VISA� and MasterCard� (and their member banks):
Areas of business, types of information received, and how that information is received are described in the column labeled "Primary Qualification Criteria". The fourth parameter is set forth in its own column, labeled "Card Type". Note that types of information that may be received include, for example, a card number, a card security code number, a zip code, a billing address, a debit security code, having an address for the customer included with the transaction, and a customer's signature. The types of ways in which information may be received include, for example, in person (e.g., card present or not present), electronically over the Internet, over the phone, through a card-swipe card reader, through a key-faub reader, through manual entry by a non-card holder, and through card-holder entry into a keypad. Types of cards used include, for example, a credit card, a debit card, a key faub, and an account without a physical device.
As is apparent from the above table, the depth and breadth of factors that may go into how a card issuer assigns interchange categories can be quite complex.
Some example interchange categories are illustrated in
At arrow 4-2, the category entity determines, for each business type, which higher-cost interchange categories may be replaced by one or more lower-cost interchange categories. Some of the parameters are set by the category entity as ones that do not easily change, such as the type of card used and whether the card was present or not (e.g., swiped at the merchant or entered via an Internet sale). This aids in building a map, for each business area, of higher-cost interchange categories that may be replaced by lower-cost interchange categories by changing parameters that either are relatively easy for a merchant to change or that a merchant is willing to change (e.g., requiring that no debit cards be used is often not acceptable to a merchant because it may reduce sales). Note that there may be intermediate levels in this map; some interchange categories that are lower cost in relation to one higher-cost interchange category may themselves be considered a higher-cost interchange category in relation to some other, still lower-cost interchange category(s).
In this example the business type is retail education, that is, merchants that accept retail sales in a not-for-profit educational entity. In this business area, there are many interchange categories that may potentially be altered to lower fees. Particular examples of these are described later below.
At arrow 4-3, the category entity determines parameter changes that need to be implemented to have transactions currently assigned a higher-cost interchange category to instead be assigned a lower-cost interchange category. As noted above, these parameters may include some but not all parameters or types of parameters.
For example, assume that one of many interchange categories that may be replaced for lower-cost categories is the VISA� EIRF interchange category. This category may be replaced by any one of the four categories listed above and shown in
At this point, the category module, through the category entity, knows which interchange categories may be replaced by lower-cost interchange categories for each potential business area for which a merchant may be qualified and the parameters needed to affect this change. With this information, the tools proceed to arrow 4-4.
At arrow 4-4, the category entity receives or determines a correct area of business for a particular merchant. The category entity here includes involvement of a person knowing details about the merchant at issue. In some cases, however, the category entity may determine this implicitly based on interchange categories assigned to the merchant by the card issuer. Basing this determination on information from the merchant processor or based on the card issuer's determination, however, may reduce the effectiveness of the tools auditing functions.
In this example the category entity determines, based on information from the national bookstore chain indicating that the merchant sells textbooks for a university bookstore, that the merchant operates in a Retail Education area of business. If this business area is not currently being assigned by the merchant processor, the category module may indicate this to a user so that the user can ask for the area of business to be changed. In this case the merchant was incorrectly assigned as a retail (not education) area of business in its historic merchant-processor statements and so qualifies for the VISA� CPS Retail 2 Emerging Markets interchange category without implementing a change to its procedures. Instead, the merchant must have its merchant processor change its area of business with regard to the card issuer.
Any of the prior actions of arrows 4-1 to 4-4 may be performed in the category entity as software or a person or both. Thus, a person or software may determine and provide to the category module the current interchange categories, their parameters, fees, and which can be replaced for each business area. If the category entity is software, it provides the results of arrows 4-1 to 4-4 to the category module through APIs, other software-to-software communication manners, or simply by being integral with the category module. If the category entity is a person, the category entity provides the results by data entry or other format usable by the category module. The category entity may also be both software and a person interacting, such as by the category entity retrieving parameters and the person deciding on the correct business area for a particular merchant. This communication is sent and received at arrow 4-5.
At arrow 4-6, the category module receives an interchange category assigned to transactions received by the merchant (e.g., in any of the merchant-processor statements in the last 12 months). Here the category module receives a merchant processor statement for the merchant, the following portion of which is stored in relational database 106 and provided to the category module:
Also at arrow 4-6, the category module receives credit-card transaction data for transactions assigned the higher-cost interchange category (shown above). Based on the analysis by the category entity for any merchant having this business type, the category module now acts on this information based on the merchant having transactions assigned one of those higher-cost interchange categories.
Here the university bookstore merchant has 570 transactions totaling $34,317.10 and was charged $846.29 in interchange fees for the VISA� EIRF category. The category module also knows which lower-cost interchange categories may replace the EIRF category, namely VISA� CPS Retail, VISA� CPS Retail Key-Entered, VISA� CPS Card-Not-Present, and VISA� CPS Retail 2 Emerging Markets. The category entity determines that the other four categories shown in
The category entity determined, at arrow 4-2, that each of these four have lower fees based on their published fees rates—e.g., that EIRF costs 2.30% and $0.10 per transaction but that VISA� CPS Retail 502 costs 1.54% and $0.10 per transaction, VISA� CPS Key-Entered 504 costs 1.85% and $0.10 per transaction, VISA� CPS Card-Not-Present 506 costs 1.85% and $0.10 per transaction, and VISA� CPS Retail 2 Emerging Markets 508 costs 1.43% and $0.05 per transaction.
The category entity also determined at arrow 4-2 that each of these better categories is one in which the merchant has a relatively high amount of control over the parameters. The merchant is unlikely to be able to change a parameter from being a debit card to being a credit card unless the merchant wants to require that no debit cards or no credit cards be received. This is not often something a merchant is willing to do because it adversely affects sales. Thus, the category entity determines that the EIRF category may be replaced by any of the other four categories based on the information received and/or how the information is received. These parameters are often easier for a merchant to control and also ones that the merchant is willing to implement. Here the category entity includes decision making by a skilled person, though this decision-making may also be made based on algorithms approximating the skilled person's assessment.
At arrow 4-3, the category entity determined what parameter needs to be changed to alter the current category assigned to one of the better potential categories. As noted above, some of this analysis may already be done by the entity deciding to include only those categories having parameters that the merchant can easily change or is willing to change.
The VISA� EIRF category is assigned to cards that are classified consumer credit (e.g., non-business credit cards) where the information received and how it was received is not taken into consideration. Here the category entity determined that if the transaction was taken in person that, by requiring a signature with either a card swipe (VISA� CPS Retail) or a manually keyed in (VISA� CPS Retail Key-Entered), the transaction could instead by assigned these other categories. If, on the other hand, the transaction was taken without the person and card present, that by requiring a person handling the merchant (e.g., the device or account through which card numbers are entered) to response "No" to a query asking "Is the card present" that the transaction may be assigned a VISA� CPS Card-Not-Present category. Further, than VISA� EIRF may be replaced by the VISA� CPS Retail 2 Emerging Markets category simply by having the merchant processor change the business area for the merchant.
These parameter changes are illustrated in
At arrow 4-6 the category module received credit-card transaction data for transactions assigned the higher-cost interchange category, such as from relational database 106. Based on the analysis by the category entity for any merchant having this business type, the category module now acts on this information based on the merchant having transactions assigned one of those higher-cost interchange categories.
At arrow 4-7, the category module calculates a potential fee savings if the transactions assigned the higher-cost interchange category were instead assigned the lower-cost interchange category. Here the category module calculates a fee savings between the VISA� EIRF category and each of the other four categories:
VISA� EIRF Fees are:
CPS Retail Potential Fees and Savings would be:
CPS Retail Key-Entered Potential Fees and Savings would be:
CPS Card-Not-Present Potential Fees and Savings would be:
At arrow 4-8, the category module provides these potential savings and the parameter changes needed to change the EIRF category to one of the better categories. The category module provides this information to report generator module 118, which in turn lists the parameter changes needed and the potential savings associated with each. For the merchant processor statement above, the savings and parameter changes are:
Swipe Card (if needed) and Get Signature, Potential Savings would be:
Key-Entered Card Number (if needed) and Get Signature, Potential Savings would be:
Answer "No" to Query, Potential Savings would be:
Alter Business Area to "Retail Education", Potential Savings would be:
At this point various potential fee savings may be proposed to the merchant, such as ways to upgrade some types of future transactions from unfavorable (higher-cost) categories to more-favorable (lower-cost) categories. VISA� EIRF can be upgraded to the first three categories above by changing order-intake procedures. The tools may determine actual fees saved (not potential) based on these and other changes by comparing the adjusted baseline card-issuer interchange rate for the client with a current rate being assessed after implemented suggested parameter changes. Determining actual savings is described in the following section.
The tools may perform actions 4-6 and 4-7 many times, such as once for each interchange category that may be replaced by a lower-cost interchange category. If the national bookstore chain has 2,000 merchants and each has been assigned five categories that could be improved, the tools may perform these actions 10,000 times and for many different business areas. After performing these actions the tools may provide a detailed report on the potential savings available to each merchant or all the client's merchants based on savings for all its merchants.
In the following section, the tools find savings between an adjusted baseline interchange rate and a current rate. The current rate, as used therein, may be the rate after the suggested parameters changes are made by the client through its merchants. In so doing, the suggested changes provided by the category module may, when implemented, save a client a substantial amount of money in fees.
Determining Card-Issuer Interchange-Fee Savings
This section continues the above example in the context of credit-card transaction data being made available to interchange module 116 to determine a savings between an adjusted baseline interchange rate and a current rate. This data is made available following its being provided in
At arrow 6-1 in
At arrow 6-2, the interchange module adds up all the fees and dollar volumes on which interchange fees are charged for each merchant over the current billing cycle. Here the "Discover Authorization" fees and the terminal fees are excluded, as they are not an amount on which a card-issuer interchange fee is charged.
Thus, interchange fees for the particular merchant during the current billing cycle are:
The interchange module does this again for every merchant. By so doing, the interchange module determines the client's total fees and dollar volume on which the interchange fees were based for the current billing cycle.
At arrow 6-3, the interchange module divides the total interchange fees by this dollar volume to provide a current card-issuer interchange rate for the current billing cycle for the bookstore. For the particular merchant above, assume that the interchange dollar volume is $148,411.43. Thus, the current card-issuer interchange rate is:
For the bookstore, assume that the current total interchange fees are $598,000 and total dollar volume on which these fees were charged is $31,000,000. The bookstore's current card-issuer interchange rate is:
At arrow 6-4, the interchange module determines a rate difference between the bookstore's current rate and the bookstore's adjusted baseline card-issuer interchange rate by subtracting the current rate from the adjusted rate. The bookstore's rate difference is:
At arrow 6-5, the interchange module determines the interchange fee savings by multiplying the bookstore's rate difference by its dollar volume on which interchange fees were applied. The savings are:
At arrow 6-6, the interchange module provides the bookstore's savings to report generator module 118. The report generator module receives the savings and generates a report that is human readable, shown at arrow 6-7 and with report 602. This report may be a window on a computer screen (e.g., a graphical user interface) or a PDF file for reading on a computer screen or printing and viewing on paper. This report generator may also, in conjunction with the interchange module or independently, multiply the savings by a particular percentage, such as one contractually agreed-on by the client (e.g., the bookstore) and the user of the interchange module to assess a payment for services rendered in reducing interchange fees.
The interchange module performs the actions of arrows 6-1 to 6-5 using a savings ETL package 604, shown included in the interchange module in FIG. 6. The act of extracting card-issuer interchange fees and dollar volumes of arrow 6-1 is performed by an Extract portion of an ETL process caused by the computing device executing the savings ETL package. The acts of adding up all the fees and dollar volumes, dividing the total interchange fees by this dollar volume, subtracting the current rate from the adjusted rate, and multiplying the bookstore's rate difference by its dollar volume on which interchange fees were applied, at arrows 6-2, 6-3, 6-4, and 6-5, respectively, are performed by a Transform portion of this ETL process. The saving ETL package also provides the bookstore's savings to the report generator module as described at arrow 6-6 using a Load portion of the ETL process.
Auditing Interchange Categories
This section sets forth one example way in which the tools audit interchange categories assigned to credit-card transactions. It continues the example of the bookstore, but may be separate from or integral with the Building and Adjusting Baseline Interchange Rates, Auditing and/or Determining Ways in which to Alter Interchange Categories, and Determining Card-Issuer Interchange-Fee Savings sections.
In this example, interchange module 116 determines, automatically and without user interaction, whether interchange categories assigned to a merchant's credit-card transactions are correct. The interchange module, in conjunction with other elements of exemplary embodiment 100, can determine whether hundreds of thousands of credit-card transactions or groups of transactions were assigned a correct interchange category.
Turning to
These published interchange-category parameters are published by the card issuer of that interchange category, such as VISA� or MasterCard�. They may be published on a website, made available through APIs, or distributed to interested parties in electronic or paper form. In any case, these published interchange-category parameters are entered into relational database by data-entry entity 104 in any of the manners described above for entering data (not shown in
At arrow 7-2, the interchange module receives a merchant's interchange-category parameters. Continuing the bookstore example, assume that the interchange module receives interchange-category parameters for all of the bookstore's merchants and that one of its merchants is in an education business section but has a taxable status (e.g., a for-profit text-book store owned by the national bookstore chain). These parameters are received by the interchange module from the relational database after being stored in the database by data-entry entity 104 either manually or electronically.
At arrow 7-3, the interchange module receives credit-card transaction data indicating groups of credit-card transactions and their assigned interchange categories. Assume that the merchant at issue is the for-profit text-book store owned by the national bookstore chain.
Consider the following groups of transactions and their assigned interchange categories for this text-book store:
Note the bolded group of credit-card transactions and their category: VISA� Education (not a real category; it is for example purposes). As noted above, this category requires that the merchant receiving the credit-card transaction be non-taxable and in the education business sector.
At this point the interchange module has the following information: the published interchange-category parameters for VISA� Education; the interchange-category parameters for the text-book store; and that a group of transactions have been assigned this VISA� Education category. The interchange module also has credit-card transaction data about this group of transactions: the number of transactions; amount of the transactions; and amount of the interchange fee charged.
At arrow 7-4, the interchange module determines whether or not the interchange categories assigned to all transactions and for all of the client's merchants during a billing cycle are correct. Continuing this example, the interchange module compares the interchange-category parameters for the text-book store with those required for the VISA� Education interchange category. The VISA� Education interchange category requires that the merchant have a non-taxable status. Here the text-book store is for-profit and so has a taxable status. Thus, the interchange module determines that the group of transactions assigned the VISA� Education interchange category were incorrectly assigned this category.
For each transaction or group of transactions that are correctly assigned, the interchange module records this finding in the relational database. For each transaction or group of transactions that are not correctly assigned, the interchange module can proceed to indicate this finding and the other pertinent information (the merchant, the reason the assigned category was incorrect, and credit-card transaction data about the transaction(s)) to report generator module 118 at arrow 7-5, or continue first to 7-6 to compute a savings or loss.
At arrow 7-6, the interchange module determines the correct interchange category based on comparing published interchange-category parameters for various interchange categories with the interchange-category parameters for the merchant.
For the VISA� Education group of transactions the interchange module determines that VISA� EIRF DB is correct because VISA� EIRF DB applies to merchants with a taxable status with an education business section (and others), and because the transactions were handled in a particular manner (i.e., following EIRF DB's requirements).
At arrow 7-7, the interchange module determines the correct interchange-category fee that should have been charged. Here EIRF DB should have been applied instead of Education. VISA� Education's fee is 2.14% times the amount plus $0.10 per transaction, with a charged fee of $79.14. The interchange module determines the correct fee, which for VISA� EIRF DB is:
For the group at issue, this computes to:
At arrow 7-8, the interchange module determines the savings or loss, here:
Following arrow 7-8, the interchange module sends this savings information to the report-generator module according to arrow 7-5.
The interchange module performs the actions of arrows 7-1 to 7-8 using an Audit ETL package 702, shown included in the interchange module in
Other Embodiments of the Tools
Processes 800 and 900 of
Block 802 stores credit-card transaction data and other information, such as interchange categories and their published parameters. This information may be stored into a rational database in one or more textual, human-readable formats or in one easily-machine-usable format. In cases were it is stored in more than one format or in a less-desired format, it may be transformed into a format designed for consumption by the tools, such as interchange module 116. The stored credit-card transaction data may include any information made available through a merchant-processor statement or made available by a merchant processor, including individual transactions. Examples of this act of storing and various types of information and credit-card transaction data, as well as an example of transforming formats, are set forth above.
Block 804 receives credit-card transaction data from a rational database for credit-card transactions accepted through one or more merchants and/or other information. Each of these merchants may be identified by its own merchant identifier. As noted above, the data may be received by retrieving the credit-card transaction data using an Extract portion of an Extract, Transform, and Load (ETL) process. This credit-card transaction data and other information may be received periodically, such as each calendar month for billing cycles, or historical, such as to build a baseline interchange rate as described above.
The information received may be for multiple merchants, each of the merchants having received customer purchases during a same time period, such as a particular billing cycle, or having batched their respective customer purchases during this period. The merchants can be associated with a single client or otherwise. If associated with a single client (e.g., the 2,000 merchants of the national bookstore chain), each may be associated based on its merchant identifier and a list of merchant identifiers for that single client.
Block 804 may receive the information based on its merchant identifier, such as all information from merchant-processor statements having a particular merchant identifier. Thus, the tools may receive, automatically, without user interaction, from a relational database, and using the merchant identifiers, credit-card transaction data for credit-card purchases for all merchants of a particular client.
Block 804 may also receive interchange parameters. Here published interchange parameters may be for each of interchange categories assigned and each other type of interchange category to which each of the credit-card transactions of a merchant may potentially be correctly assigned. Examples of these interchange parameters are set forth above.
After receiving the information at block 804, the tools may proceed to audit interchange categories assigned or calculate savings since an historical period or both. The discussion turns first to auditing interchange categories (starting at block 806) and then to calculating savings (starting at block 812).
Block 806 determines if an interchange category assigned to a particular transaction or group of transactions is correct. Block 806 may do so for groups of transactions based on information in a merchant-processor statement or otherwise made available, such as described in the bookstore examples above.
Block 806 may also do so for individual transactions. Determining correct interchange categories for individual transactions may be performed like groups above, but doing so for individual transactions permits greater analysis because each transaction may or may not be correctly assigned based not just on a merchant's status, but also the specifics of a transaction.
For example, if a particular transaction is assigned a Card Not Present type of interchange category and the tools have information about that particular transaction, the tools may determine, based on parameters for the transaction, such as the credit card actually being present at the time of the transaction, that it was incorrectly assigned.
In some embodiments, block 806 may be performed using an Extract portion of an Extract, Transform, and Load process, such as described above (e.g., ETL 206 of
Following block 806, the tools may proceed to indicate its findings or proceed to determine a savings or loss based on the incorrect assignment at block 808. In either case block 810 provides results of the tools' determination, here that one or more transactions have been assigned an incorrect card-issuer interchange category.
Block 808, responsive to the tools determining that an interchange category was incorrectly assigned to a transaction or group of transactions, determines a savings or loss between the incorrectly assigned interchange-category's rate and the correct interchange-category's rate. The tools may do so by calculating a correct fee for the applicable transaction at the correct rate and subtracting the incorrect fee. The tools may provide this information to block 810 to report.
Starting with block 812, the tools build a baseline card-issuer interchange rate for a merchant or group of merchants. Block 812 may do so by receiving credit-card transaction data for multiple historical billing cycles and for each merchant of a group of merchants, such as those associated with a particular client. The tools may base this baseline rate on card-issuer interchange fees associated with card-issuer interchange categories assigned to credit-card transactions and dollar volumes on which the card-issuer interchange fees are charged. The card-issuer interchange fees and dollar volumes can be received from multiple historic merchant-processor statements of the particular merchant and over a historical period.
In the bookstore example above, the tools, through interchange module 116, extract card-issuer interchange fees and the dollar volumes from credit-card transaction data in a relational database and transform the card-issuer interchange fees and the dollar volumes into the baseline card-issuer interchange rate by dividing the card-issuer interchange fees by the dollar volumes. In some examples described above, the interchange module performed these acts automatically using an ETL process.
With the baseline determined, block 814 adjusts the baseline card-issuer interchange rate based on rate changes. Block 814 adjusts the baseline rate based on rate changes made during or after the historical period to the card-issuer interchange categories assigned to credit-card transactions of the particular merchant over the historical period.
In more detail, the tools may receive a rate change to the particular card-issuer interchange category for the group of credit-card transactions assigned to that category, determine a fee change based on the dollar volume of the group and the rate change, receive or determine a total interchange fee charged during the historical period based on a total dollar volume and the baseline card-issuer interchange rate, and add or subtract the fee change for the group from the total interchange fee charged during the historical period. By so doing the tools provide an adjusted baseline interchange fee, which the tools divide by the total dollar volume to determine an adjusted baseline interchange rate.
In the bookstore example, for instance, the tools adjusted the baseline interchange-category rate based on an interchange-category's rate changing from 1.54% and $0.10 per transaction to 1.55% and $0.11 per transaction.
With the adjusted baseline interchange-category rate available, the tools may proceed to blocks 816 and 818 or proceed direct to block 820.
Block 816 receives card-issuer interchange category parameters sufficient to determine parameter changes that are effective to replace a higher-cost interchange category with a lower-cost interchange category. The parameters received may include all parameters by which card issuers decide which interchange category to assign to transactions, such as a merchant's area of business, information received for a transaction, how information was received for the transaction, and a type of card used in the transaction. Examples of these parameters are set forth in the examples illustrated in
Block 818 provides parameter changes needed to reduce fees. Block 818 may also provide the potential fee savings associated with each of these changes, such as indicating that a merchant will save $4,302 on a same amount and number of transactions as a prior merchant processor statement if the merchant will implement a new data-intake procedure (e.g., entering the 3-digit number on the back of a credit card for an over-the-phone transaction). Examples of parameters changes and potential savings are described above in relation to
Block 820 determines a current card-issuer interchange rate for a current billing cycle. This current rate may be lower than it would otherwise have been because a merchant implemented parameter changes suggestions by the tools at block 818. Blocks 816 and 818, however, are not required for the tools to implement block 820 or any other block of process 800.
The tools perform the actions of block 820 by calculating a card-issuer interchange fee for each of the merchants and the dollar volume of credit-card purchases for all of the merchants and on which the card-issuer interchange fees charged are assessed. Dividing the total fee for all merchants by this dollar volume results in a current interchange rate averaged over all the merchants.
The tools then determine a rate difference between the adjusted baseline and the current rate at block 822. Block 822 may determine this difference automatically by subtracting one from the other.
Block 824 determines a fee savings based on the rate change (if any). The tools may determine this savings, automatically and without user interaction, based on a credit-card dollar volume for the credit-card transactions during the current billing cycle and the determined rate difference.
Responsive to determining a fee savings at block 824 and/or a fee savings based on an incorrectly assigned interchange category at block 808, the tools provide these fee savings at block 810. Block 810 also provides other information and/or performs some calculations. In one case the tools provide a report, in a human-readable format, showing which of the credit-card transactions to which an interchange category assigned were not correct and an associated fee savings or loss. In another case the tools provide a report to a particular client setting out various fee savings or net savings and a contractually agreed-on percentage of the fees due.
Each of the above acts involving receiving or retrieving information of any sort, a calculation (e.g., add, divide, subtract), or enabling the tools to provide results may be performed automatically and without user interaction, such as through execution of one or more ETL packages. Example ETL packages are described as part of the bookstore example above. The tools, through these ETL packages or otherwise, may provide reports to users that compile savings over hundreds of thousands of credit-card transactions.
Process 900 in
Block 902 receives interchange categories and one or more of their parameters, the parameters including: merchant's area of business, information received for a transaction, how information is received for a transaction, and type of card used in a transaction. The tools may receive all possible interchange categories or a subset of these. As noted in the above example, there are currently 129 VISA� and MasterCard� interchange categories, most of which have parameters used to determine when each is assigned to a credit-card transaction. The tools may actively retrieve or receive most-current parameters and pricing so that the tools' analysis is kept up-to-date.
Block 904 receives transaction information for a particular merchant. This transaction information may include which transactions have been assigned which categories and the merchant's currently assigned and/or potential business area. The transaction information may include credit-card transaction data and be received from a relational database in an easily-computer readable format, as provided in some examples above. The transaction information may group transactions or list them separately. Also, the transaction information may indicate the parameters and pricing for each category or may not. If this information is not included the tools may retrieve or receive it, such as at block 902.
Based on the information received at blocks 902 and 904, block 906 determines, for at least one assigned interchange category received at block 904 and at least one interchange category received at block 902, which potential interchange category may be assigned instead of one currently assigned. Thus, the tools may determine which interchange categories have a lower cost than a currently-assigned interchange category. In one example above, the tools act through the category module and its entity to determine which categories having lower fees than others and also have parameters that may realistically be changed by the merchant. The parameter changes do not necessarily have to be implemented by the merchant making some sort of change; as noted above, the change may be changing the merchant's area of business with the card issuer and/or merchant processor. In this case the fee savings may even be retroactive, and thus actual rather than potential (e.g., by changing a merchant from "retail" to "retail education").
Block 906 may determine all interchange categories that have better pricing, and some or only the best based on changes a merchant is likely to want to make. The tools, for example, may only indicate interchange categories that may be attained through changes that do not include changing the type of card, as this may be difficult to do. Also for example, a merchant may be informed only that the best potential savings are to change its area of business to improve a particular interchange category (e.g., from EIRF 510 to CPS Retail 2 Emerging Markets 508 as shown in
Block 908 determines a potential fee savings if the one or more transactions assigned an interchange category were instead assigned another, lower-cost interchange category. The tools may do so for all possible interchange category changes or a subset, as noted above. In the above example, the tools act through the category module to determine potential interchange category improvements and a potential savings for each.
Block 910 provides the potential fees savings and, in some cases, the parameter change needed to potentially bring about these potential fee savings. Thus, block 910 may indicate (e.g., through report generator module 118) to a merchant or client that by requiring its personnel to answer a query with "No" for some types of transactions will potentially save the merchant (and the client) a certain amount of money in interchange category fees assessed by a card issuer (e.g., VISA� or MasterCard�).
In some cases the suggested parameter change may already be performed by a merchant. In these cases, the merchant may indicate this to its merchant processor and thereby retroactively save fees. In at least this way the tools may act to audit interchange category fees in additional to the manners set forth in the section entitled Auditing Interchange Categories.
Each of blocks 902, 904, 906, 908, and 910 may be performed automatically and without user interaction. Thus, the tools (e.g., category module 120) may act to receive interchange categories and their parameters (e.g., from card issuers), receive credit-card transaction data (e.g., from merchant processors or a relational database after they were previously gathered and transformed) for a merchant, determine parameter changes, determine potential fee savings, and provide these parameters and savings. Note also that each of these blocks may be performed many, many times. For the national bookstore example, the tools may find potential fee savings for dozens of currently-assigned interchange categories for each of the 2,000 merchants of a client. All of this may be performed automatically such that a client receives, either for all merchants or merchant grouped by similarities, parameter changes and potential fee savings if these parameter changes are made. As noted above, interchange category fees amount to many billions of dollars worldwide. The tools may save clients and their merchants a significant amount of money in these fees by analyzing the interchange categories and each merchant's transaction information.
The above-described tools are capable of altering to which interchange categories credit-card transactions are assigned and accompanying potential fee savings. The tools may do so automatically and with user interaction for one or even hundreds of merchants, thereby potentially saving the merchant or a client associated with these many merchants thousands if not millions of dollars in interchange fees. Although the tools have been described in language specific to structural features and/or methodological acts, it is to be understood that the tools defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the tools.
Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Original Image


text:
This year, we continued on our three year journey of transformation to become the clear choice. We stimulated growth in our business, turned the spotlight back up on our Values and reflected on and communicated our Purpose
Tech Monitor UK is a joint report released by KPMG and Markit which looks at the health of the UK technology sector.
Explore why technology firms should choose to invest in the UK. We consider what the UK currently has in its favour as it battles for technology investment.
KPMG has recently published the 2014 Guide to Directors' Remuneration, a survey which analyses trends in FTSE 350 directors' pay.
We help our clients understand current issues and future trends in the world of work, and identify how they can enhance organisational performance through their people.
Explore the opportunities available for school and college leavers at KPMG.
Find out about careers for graduates from all degree disciplines in Audit, Tax, Advisory, Technology, Marketing and HR.
Keep up to date with the latest news and views from KPMG in the UK by following our twitter feed.
KPMG's leadership blogs brings you insight, opinion and debate from our senior partners and industry experts.
Situated in Dukes Keep close to the city centre, the local team works with family-owned and private equity-backed businesses through to AIM-listed and FTSE 250 companies throughout Hampshire and Dorset.
The team of 100 audit, tax and advisory professionals is led by senior partner Will Smith, an auditor with over 20 years experience.
KPMG's Southampton office is committed to seeking out and highlighting the very best business talent the South Coast offers through its annual sponsorship of the prestigious Dorset Business Awards and Hampshire Business Awards.
The team is also involved in organisations such as Business Southampton, Southern Society of Chartered Accountants (SOSCA) as well as local Chamber events.
Will Smith
Office Senior Partner
Steve Masters
Partner, Audit
Paula Claisse
Partner, Tax
Wendy Wardell
Director, Restructuring & Courtwork
Harry Mears
Associate Partner, Audit
Will Smith
Office Senior Partner
Steve Masters
Partner, Audit
Paula Claisse
Partner, Tax
Wendy Wardell
Director, Restructuring & Courtwork
Harry Mears
Associate Partner, Audit
Dukes Keep Marsh Lane Southampton SO14 3EX
Tel: (023) 8020 2000
View map (PDF 128 KB)
© 2015
KPMG LLP, a UK limited liability partnership, and a member firm of the KPMG network of independent member firms affiliated with KPMG International Cooperative, a Swiss entity. All rights reserved.
KPMG International Cooperative ("KPMG International") is a Swiss entity. Member firms of the KPMG network of independent firms are affiliated with KPMG International. KPMG International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis-à-vis third parties, nor does KPMG International have any such authority to obligate or bind any member firm.

subset: commoncrawl


text:
My nightmares never star monsters nor is anyone is ever trying to kill me. In my nightmares people behave strangely and tell me, with the utmost urgency, things that don't make any sense. This is why I love David Lynch. His movies are exactly like my nightmares. Everything is lit strangely from below, everyone is shot in uncomfortable close ups, the dialog is often delivered deliberately wooden and awkward. People change, I change, locations change at the drop of a hat and there is a pervasive air of confusion about the entire affair. My nightmares and David Lynch's movies are suspiciously similar in tone.
I took in Lynch's latest, Inland Empire, last night and I'm pleased to report that nothing has changed. Short of the Alan Smithee cut of Dune, this is probably his longest movie with a runtime of over three hours. Three hours of sweet, sweet madness. When I was in school, I had discussions about Lynch's movies with a film major and he laid the usual film school bullshit on me about hidden meaning, deep metaphor and everything you would expect from a guy in horn rimmed glasses reading a book about the French new-wave. He could never accept my belief that Lynch's most confusing, stream of consciousness movies weren't hiding anything, they are what they are and it's up to you to connect the dots in your own way. This way, his movies have a different story every time you watch them.
Truth be told, my favorite Lynch movies are his most lucid. The Elephant Man, Blue Velvet, Fire Walk With Me. While Blue Velvet is his single greatest achievement in my opinion, Dune also ranks high on my list. I'm a huge fan of the novel and despite a few creative departures, I think the movie is the shit.
Alright. Deep breath. Get comfortable. If it wasn't rough enough encapsulating the plot of a Frank Herbert novel, matters are complicated further by adding David Lynch to the director's chair.
The planet Arakis is the only source of the most precious commodity in the known universe, the spice melange. Thousands of years into the future, after man is driven to near extinction by thinking machines of its own creation, man outlaws most technology and through use of the spice, they elevate their consciousness. Some spice users have trained their expanded minds to think like computers. Some, a clergy of women, can read thoughts and feelings and some have developed the ability to bend space with their minds making faster than light travel possible. The Emperor of the Universe, in fear of the rising popularity of House Atreides in the Lansraad, a collective of Fiefdoms, unseats the present Lord of Arakis, Baron Harkonen, sworn enemy of the Atreides family, and puts Leito Atreides in control of the planet with a secret conspiracy to hand Leito to Harkonen and destroy House Atreides.
Got it?
Leito's son and heir apparent to the Atreides throne is Paul. Paul is an anomaly. The Benegeserit Order, who devote their lives to developing their mental skills and maintaining a hard-line lineage of marriages and births in order to birth the Kwisatz Haderach, a messiah-like figure, fear Paul because his mother, the Duke's wife, disobeyed their orders to bear a girl who would be married to the Harkonen son, Feyd Rautha. Paul's birth, however, applies to a prophecy that the Kwisatz Haderach would be born earlier than first thought and would destroy the current order of rule in the universe.
The Atreides are uprooted from their home on Planet Caladan and set up shop in the former Harknone palace and get a look at Arakis. The spice is mined in the desert by the dilligent workers of the Choam Corporation but their efforts are constantly threatened by giant worms who live in the desert. The native people of Arakis, The Fremen are a constant and intimidating presence as well. Their exposure to spice, over generations, has turned their eyes a brilliant blue and legends abound of fearsome guerilla fighters who live in the deep desert, thought to be uninhabitable. Shortly after the Duke and family get settled, advisors to the Atreides turn on them and Harkonen, aided by the Emperors disguised elite storm troopers invade the Atreides palace, nearly killing the Duke and kidnapping Paul and his mother Jessica where they are to be abandoned in the deep desert. Paul, using his inherited Benegeserit talents, manages to get the upper hand against the Harkonen captors and crashes in the desert where they stumble upon a Fremen settlement.
Paul, through a fight with the Fremen leader, gains their acceptance and becomes one of them, teaching them to fight with a sound-based attack called The Weirding Way (in the book, a martial art) and eventually takes his Fremen name, Muad'ib. Meanwhile, his mother, Jessica, drinks the water of life, a high concentration of spice taken from the bile of a dying sandworm, to awaken her ancestral knowledge, gaining the knowledge of every benegeserit that came before her in her bloodline. Jessica is pregnant and causes an early birth of Paul's sister, the youngest, fully aware Benegeserit in the history of the order. Over years of training and hit and run strikes against the Harkonen, Muad'ib and the Fremen prepare to take on the Harkonens, destroy them and take control of Arakis back from the Harkonen, the Lansraad and the Emperor.
Make no mistake, this is heavy sci-fi. It's epic and like many of the best-known sci-fi and fantasy, it creates an entire world with a sprawling back story and a multi-faceted narrative. Herbert's novel bounces around to all the major players so you know what's going on at all times. Lynch was tasked with adapting this huge novel to screen, an unenviable task if I've ever heard of one.
The Dune movie also marks one of the greatest what could have been moments in the history of film that few people have ever heard about. During the 70's, with money from a French investor and The Rolling Stones, ultra-weirdo Alejandro Jodorowsky was set to begin production on a ten hour adaptation with contributions from Salvador Dali, Dan O'Bannon, H.R. Giger and Jean "Moebius" Giraud, among others. The soundtrack was to be provided by Pink Floyd. What followed during preproduction were money problems, fights between Jodorowsky and Dali, Dan O'Bannon's nervous breakdown and a massive, 14 hour script. Giger was set to design the Harkonen set pieces and Moebius, the Atreides. According to Herbert, the preproduction phase was insane but he was happy with the outcome. Unfortunately, the bottom fell out and the project went from director to director, settling on Ridley Scott at one point and finally finding a home in the hands of David Lynch. Lynch had just won tons of acclaim for his movie, The Elephant Man, and offers to direct other features were pouring in (including a shot at Return of the Jedi!). Dino De Laurentis handed it off and the rest is history.
This being Lynch's third feature, you can see a lot of his trademark techniques developing. With conspiracy and secrecy playing such a large role in the story, Lynch knew that he was going to have to provide a way to convey the inner monologues of the characters so rather than adjust the script to have people discussing their thoughts as other directors might, Lynch adds the soliloquy moments as the characters stare off on screen while a narration plays over the scene, quietly, to let you know what they're thinking. A weird technique to add to a movie, no doubt. The movie also takes some liberties with the source material. In the novel, the weirding way is a sort of martial art, like kung fu, that allows Paul to move extremely fast. In the movie, the weirding way is a vocal technique, amplified through gun-like modules that project the sound into a destructive force. The benegeserits also aren't psychic, they're merely super-keen. There's a lot that is changed but it suits the script well and trims a lot of time. As much as I'd like a 14 hour Jodorowsky Dune adaptation, this is probably the closest thing to the novel we'll ever get.
The cast is suitably huge for such an undertaking. Kyle McLachlan, Patrick Stewart, Jack Nance, Sting, Brad Douriff, Dean Stockwell, Jurgen Prochnow, Sean Young, the list goes on and on. Despite the near pychedelic script, everyone turns in a solid performance. Also, laugh all you want at Sting and his space undies, there was no one else on earth born to play that part. Feyd is a slight, androgynous dude and so is Sting. It was a match made in heaven. The undies are a little much, though.
Despite the massive scope, great acting and special effects, just about every critic on earth took time out of their busy schedules to lay a huge steamer on this movie. After some research on this baby, I found out that the only critic who was ever kind to it was, oddly, the infamously grouchy Harlan Ellison. Like wine, though, the movie has matured in a lot of viewers eyes and like few sci-fi flicks of the time, it doesn't show its age quickly. A cult has rallied around it and because of this, Dune earns a spot on my review list.
Last year, they released a stellar collector's edition of the DVD containing shitloads of extras, Lynch's theatrical cut of the movie as well as the three hour extended cut that begins with a narration of the back story accompanied by paintings of what is going in the known universe leading up to these events. Because I'm a huge nerd, I prefer the longer cut.
For the record. I've never seen the Sci-Fi channel movies.


text:
Heron and Lamb puts the spotlight on Mother Nature with its self-contained terrariums that can be worn anytime, anywhere. Incorporating antiqued elements and plant specimens, these beautiful adornments are organically enchanting. The Baby's Breath Necklace features a hand-cut glass pendant that contains a delicate wisp of hand-dyed baby's breath.
Vintage brass chain length: 22". Pendant measures: 1"x1". Glass is framed with silver solder. Lobster clasp.
Designed by Raven Locadia, Heron and Lamb is a feminine collection of organically inspired baubles that incorporates living and dried flowers and mosses.
This product has no reviews yet. Be the first to review this product. Write a review
Enjoy 10% off your first order*


text:
BRITTANY DONOVAN was born 13 years ago in Pennsylvania. Her biological father was sperm donor G738. Unbeknownst to Brittany's mother, G738 carried a genetic defect known as fragile X - a mutation that all female children born from his sperm will inherit, and which causes mental impairment, behavioural problems and atypical social development.
Last week, Brittany was given the green light to sue the sperm bank, Idant Laboratories of New York, under the state's product liability laws (see "Sperm bank sued for 'unsafe' sperm"). These laws were designed to allow consumers to seek compensation from companies whose products are defective and cause harm. Nobody expected them to be applied to donor sperm.
Thousands of people in the US have purchased sperm from sperm banks on the promise that the donor's history has been carefully scrutinised and his sample rigorously tested, only for some of them to discover that they ...
To continue reading this article, subscribe to receive access to all of newscientist.com, including 20 years of archive content.


text:
Forgot Password? | Not a User? Sign up
Your browser does not support iframes.
I think I have finally figured out the perfect machine for controlling those pesky spring weeds…sheep.
Well, I know it is not for everyone (and I know it cannot last much longer for me), but our pregnant herd of Katahdin ewes are let loose from their pasture in the afternoon to graze freely within the secure fencing of the entire property for a few hours.
Officials warn horse owners
of tent caterpillar outbreak
Experts are warning that a tiny critter that can have a big impact on horse owners is back. The University of Kentucky warned last week that eastern tent caterpillar eggs have begun hatching well ahead of last year.
Shelby County residents think it's important to have farmland and preserve that heritage, although they don't really know what its value is.
That was a key point found in a poll commissioned by the Shelby Area Rural Conservation group and conducted last fall among 300 residents in the county.
About 30 people turned out Wednesday night at the Shelby County Extension Office to hear those results from Martha DeReamer, CEO of Matrix Group, which gathered the data.
Absolutely nothing says spring more than the distant chorus of spring peepers.
There is a wooded stream just off Conner Station that is home to a cacophonous band of peepersall competing for as many females as they can. On a warm March evening, especially after a shower, spring peepers remind me of how glorious rural life can be. Just by listening a whole other world can be imagined.
Male spring peepers are the noisemakers. The louder and faster they peep, the luckier they get on their quest to attract females.
2 Shelby beef farms listed
on angus association registry
Dutch Creek Beef of Pleasureville and Heritage Farm of Shelbyville have been recognized nationally by the American Angus Association.
Dutch Creek had six registered Angus cows included in the Association's 2012 Pathfinder Report, and Heritage Farm had two.
I am plotting and planning and placing orders for onion sets and seed potatoes and summer crops that will be directly seeded in the garden once the temperatures really warm. I can barely stand the wait!
I have two trays of seedlings that I started about 2 weeks ago and have begun another round of kale, broccoli and Brussels sprouts in 3 more trays.
My setup is not elaborate. It basically consists of a kit that includes a plastic dome that fits over a seed tray and pan.
State to split $10 license donation
among FFA, 4-H, Kentucky Proud
Agriculture Commissioner James Comer joined Kentucky 4-H and Kentucky FFA leaders to announce that proceeds from voluntary donations to the Agricultural Program Trust Fund would be divided equally among 4-H, FFA, and Kentucky Proud.
Beef cattle sales rising
to record high levels
The mid-South states are the center of cow-calf beef production east of the Mississippi River: Kentucky ranks eighth nationally and Tennessee is ninth. With cattle prices up and exports climbing, industry officials also say it's a good time to raise beef cattle.
Brussels sprouts need a PR makeover, because no one seems to like them.
Old varieties have been greatly improved from those forced on you as a child. Equally, cooking methods probably can stand some updating from the warm, mushy, bitter Barbie-doll-sized cabbage.
Don't boil them to death, but instead try instead some quick roasting underneath the broiler.
Today we can thank breeding programs for developing a number of improved varieties of Brussels sprouts that are sweet and nutty in flavor.
9 state agribusinesses
receive development grants
USDA Deputy Secretary Kathleen Merrigan announced last week that nine Kentucky agribusiness will receive business development assistance in the most recent round of Value-Added Producer Grants (VAPG) awards.
The VAPG program provides competitive grants to individual independent agricultural producers, groups of independent producers, producer-controlled entities, and farmer or rancher cooperatives to create or develop value-added producer-owned businesses.
Copyright © 2015
The Sentinel-News is your source for local news, sports, events and information in Shelby County and Shelbyville, KY, and the surrounding area.


text:
The term 'information governance' could be changed to 'clinical governance' as part of encouraging a cultural shift in the NHS towards more information sharing, Dame Fiona Caldicott has said.
Dame Fiona is leading an independent review of information governance in the health service. Her report is due to go to the health secretary early next year.
She told the audience at EHI Live 2012 that one of the review committee's recommendations will be that the language used to describe IG needs to be simplified and clarified.
"The expression 'information governance' doesn't immediately fill people with a look of enthusiasm and excitement," she explained.
She suggested the terminology be changed to 'clinical governance' in order to encourage greater understanding and commitment to the need to protect patient privacy and confidentiality while ensuring that clinicians have the necessary information to treat their patients.
"We will recommend some ways in which the language could be clarified," she said.
She said it has become clear from her public consultation that in the NHS there is an "erring on the side of not sharing" that is not acting in the patients' interest.
She added that there is support from the population for sharing of identifiable information when it comes to their individual care, but not necessarily for commissioning or research purposes.
Dame Fiona said issues around sharing data are "most pressing" at the interface between health and social care at a time when more patients are receiving care crossing organisational boundaries.
"Anyone thinking of integrating patient pathways can immediately see there are some issues that are going to cause quite a lot of potential tension that need a solution," she explained.
"One of the areas I'm particularly concerned about is education and training. It's clear to us that there isn't the confidence we would like to see in clinicians and professionals about the rules that relate to the use of information, particularly identifiable information."
"There's a lot of work to be done in making sure staff who have responsibility in IG are aware of what their responsibilities are and how to get assistance if they are not sure of the answer to questions," she added.
Dame Fiona said there is "a lot of hiding behind the Data Protection Act and IG rules."
Much of that fear has developed from confusion around the idea of "need to know" and the large fines being handed down by the Information Commissioners Office for mishandling of patient data.
Dame Fiona said that although her committee is supportive of sanctions, the situation is made complex by the fact that money paid in fines by NHS trusts is then not available for patient care.
She explained that her review will address the necessary change in culture to address the increasing use of technology and the ability to "move data around the system."
It will also look to clarify when explicit patient consent is required before data is shared.
"There's a lot of work being done with commissioners about when they need patient identifiable data and how they can have a legal basis for that and when anonymised data can serve the purpose," she said.
© 2012 EHealth Media.
Wrong on 2 countssaywell 137 weeks ago
Firstly, as previously stated, 'Clinical Governance' already means something else.
Secondly, although 'Caldicott' deals only with patient data, from an organisation's perspective there is a lot of other information that needs governing - so 'Information Governance' is needed as a generic, catch-all term for any data that the ICO would expect us to keep secure.
Clinical GovernanceM Riches 138 weeks ago
Using the word 'clinical' in this context runs the risk of making colleagues in social care feel excluded and that this is all about the NHS and has nothing to do with them or their practice. These are the very people at the interface between health and social care that Dame Fiona is seeking to address.
Clinical Governance - already taken isn't it?stan 10 138 weeks ago
I wasn't present for this but isn't the term "Clinical Governance" already taken? For example on Wikipedia at en.wikipedia.org/wiki/Clinical_governance it defines it as "A framework through which NHS organisations are accountable for continually improving the quality of their services and safeguarding high standards of care by creating an environment in which excellence in clinical care will flourish". So can see IG being included in Clinical Governance but not actually being it entirely.
Agree with concept strongly but also not sure about the namejwaktare 138 weeks ago
I agree strongly with Dame Fiona Caldicott's concern - Information is too often confused with information security, and information security is used as a mindless excuse for what is actually very poor information governance. However as Stan 10 points out, Clinical Governance already exists, certainly in our hospital and IG is a part of CG.
We need the change in attitude delivered and in change managment, a name change can be a helpful tipping point as a tool to deliver that. My concern is that I don't think that my organisation's IG awareness is strong enough for our Clinical Governce structures to deliver good IG. Our IG committee understands the scope of IG well and are better custodians of "true" IG.
Not generally my approach to pose problems rather than solutions, in in setting I can't see an easy answer...
I agreeGeepsi 138 weeks ago
IG is already within the definition of Clinical Governance and I feel that the name change suggested would actually worsen the situation because many already forget that IG is integral to CG. (e.g. failing to communicate changes in treatment puts the patient at risk in just the same way as failing to change the treatment in the first place)
Perhaps a compromise would achieve more. Calling it Clinical Information Governance could reinforce the importance of IG in clinical care without burying it in the much larger concept of Clinical Governance
Business Development Manager (Acute Sector) - Home Based
(UK - Wide/£75k - £85k base + commission + car allowance)
Clinical Product Specialist - Home Based
(UK - Wide/£35k - £40k + bonus + benefits)
Infrastructure Engineer
(North West/£330.00 - £335.00 per day)
PIEDW Project Lead and Analyst - (NHS / Cerner Millennium)
(London (Excluding City)/Excellent Daily Rate Negotiable)
(London (Excluding City)/£250.00 - £400.00 per day)


text:
Statement of Significance (as of designation - February 24, 2004):
As the council site and central location where Seminoles, Black Seminoles, and the U.S. government met to discuss the terms of President Jacksons Indian Removal Policy, the events at Fort King represent the escalating state of relations between these groups which eventually led to the Second Seminole War, the longest and most expensive Indian war in U.S. history. This is also the site where the Seminole Indian leader, Osceola, gained national fame. Archeological investigations have confirmed the location of the site of Fort King and can continue to reveal important information about the events of the conflict and lifeways at military installations of this period.
There are no threats to the landmark at this time.
There are no changes since the last report. (2004)
Comments and questions about the database may be directed to firstname.lastname@example.com