Posts Tagged ‘transactional fraud’

The importance of card not present fraud is growing as more commerce moves online. The major card networks have reacted with systems to control the risks but the coverage of these defences is still limited. However, since chargeback rules generally protect the issuer from direct fraud losses it is common to see efforts to control this type of fraud being de-prioritised.

But the cost of fraud doesn’t only include direct, financial losses; the full impact of card not present fraud can only be seen when indirect costs are also considered. These indirect costs are both financial in nature as well as reputational. The indirect financial costs of card not present fraud include the cost of replacement plastics, the cost of the admin staff needed to manage chargebacks, the cost of funding the charges until the refund is received, etc. Reputational costs, on the other hand, are incurred when customers are inconvenienced by the forced closure of their accounts and the re-issuing of new plastics.

Both of these costs are relatively minor when card not present fraud happens on an irregular and fairly random basis. Most customers understand that fraud does happen and will not be too upset if the bank contacts them to replace a card once fraud has been detected, unless they have incurred a financial loss in the process (unlikely on credit cards if there is a decent detection system in place due to the delay between transactions and payments but fairly common for debit cards).

However, both types of indirect costs can be significant if the card issuer finds themselves under attack from a persistent fraudster. Due to the electronic nature of card not present fraud, a common weakness in the card issuing process can be exploited to make this a realistic threat. That weakness is the sequential issuing of card numbers.

Credit card numbers conform to a certain format in order to convey the specific information needed to enable international interoperability. One key part of this universal format is that the numbers are all validated by the Mod 10 check. I’m not going to discuss the mechanics of that algorithm here, the only important take-away is that it uses all the previous numbers in a fixed way to set the final number in the credit card sequence. So, working backwards it is possible to calculate whether any purported credit card number is a potentially valid one. I say ‘potentially valid’ because the algorithm cannot establish whether this number has been issued, just that it conforms to the pattern.

Unfortunately, this does not just enable international commerce it also enables fraud. If a fraudster wants to create potential credit card numbers they need only use this algorithm and a bit of basic knowledge about the other numbers to do so.

The numbers created have one major gap though, that stops them being useful – they don’t have an expiry date. Note, they also don’t have the 3/ 4 digit CVV number but not as many online transactions validate this. Without the correct expiry date the fraudulently created card number will not work, even if it matches an existing open account. Fraudsters can use trial-and-error in an attempt to establish the correct expiry date for a given number but multiple incorrect attempts will usually trigger an alert at the issuer and since there is no way for the fraudster to know for sure that such a number actually exists, the process can be interminable. As a result, card not present fraud using created numbers is not usually a major problem.

Unless card numbers are issued sequentially that is. A typical 16 digit credit card number may appear a random selection of numbers at first but as I mentioned they conform to a standard format. The first few digits identify the card network and issuing bank, the next few digits are usually used by that issuer to identify the sub-product while the last six to eight digits before the final check digit remain available for any use and it is these digits that are sometimes issued sequentially.

In an example I have seen before, the last six digits were split in two and issued sequentially so that the first card issued in a new product would end 001001X where X was the check digit, the next one would end 001002, the thousandth card would end in 002001X and so on.

This system had been used for years without problem until a specific online attack revealed its inherent weakness. A fraudster need only find one match between a valid, issued card number and its expiry date to be in the position to create the next card in the sequence knowing full well that the expiry date was almost certain to be the same. They could continue this process until the expiry date no longer worked in which case they could assume with much certainty that the expiry date had now moved up by one. So, be it through chance or trial-and-error, if a fraudster knows that card number XXXX XXXX XXXX 123X expires in May 2012 then they can be sure that card number XXXX XXXX XXXX 124X does too – using the Mod 10 algorithm to calculate the new check digit being the only other required step.

This knowledge allows the fraudster to create thousands of credit card numbers with a high probability of validity (around 80% once closed accounts, re-issued numbers, etc. are taken into account) and to use these for a large-scale attack. It is under such an attack that a card issuer can suffer significant financial and reputational costs. In the case I alluded to earlier, the premium card portfolio had been compromised in this manner and at one time cards were being compromised so quickly that some affected customers were contacted were issued new plastics only for those to be compromised too before they had even been delivered. Given that this was the premium card product it is easy to see how large the reputational costs were despite actual financial losses being insignificant.

To prevent a repeat of this situation, the issuer in question switched to randomised numbering thus breaking any logical link between the card number and its expiry date. In the new system batches of ten thousand numbers were created at a time, ordered randomly and then assigned in that order. At the same time there has been a drive to increase the coverage of Visa and Mastercard’s respective online fraud defence tools and to use the CVV code in online authorisations – something which had not been technically possible in the past. Both of these other projects address the same problem and so, to the extent that they’re implemented, will negate the benefits of random number issuing. However, where they are not widely used, random number issuing remains a low-tech but pro-active defence.

Read Full Post »

When it comes to the application of statistical models in the lending environment, the majority of the effort is dedicated to calculating the risk of bad debt; relatively little effort is dedicated to calculating the risk of fraud.

There are several good reasons for that, the primary one being that credit losses have a much larger impact on a lender’s profit.  Fraud losses tend to be restricted to certain situations and certain products: application fraud might affect many unsecured lending products but it does so to a lesser degree than total credit losses, while transactional fraud is typically restricted to card products.

I discuss application fraud in more detail in another article so in this one I will focus on modeling for transactional fraud and, in particular, how the assumptions underpinning these models vary from those underpinning traditional behavioural scoring models.

Credit Models

The purpose of most credit models is to forecast future behaviour.  Since the future of any particular account can’t be known, they do this by matching an account to a similar group of past accounts and making the assumption that this customer will behave in the same way as those customers did.  In other words, they ask the questions of each account, ’how much does this look like all previous known-bad accounts?’.

So if the only thing we know about a customer is that they are 25 years old and married, a credit model will typically look at the behaviour of all previous 25-year-old married customers and assume that this customer will behave in the same way going forward.

The more sophisticated the model, the more accurate the matching; and the more accurate the matching between the current and past customers, the more valid the transfer of the latter group’s future behaviour to the former will be.

Imagine the example below where numerical characteristics have been replaced with illustrative ones.  Here there are three customer groups: high risk, medium risk and low risk.  A typical low risk customer is blue with stars, while a high risk customer is red with circles and a medium risk customer is green with a diamonds.

A basic model would look at any new customer, in this case green with stars, and assign them to the group they  most closely matched – medium risk – and assume the associated outcome – a 3% bad rate.  A more sophisticated model would calculate the relative importance of the colour versus the shapes in predicting risk and would forecast an outcome somewhere between the medium and low risk outcomes.

An over-simplification but the concept holds well enough to suffice for this article.

The key difficulty a credit model has to overcome is that it needs to forecast an unknown future based on a limited amount of data.  This forces the model to group similar accounts and to treat them as the same.  To extend the metaphor from above, few low risk accounts would actually have been blue with stars; there would have been varying shades of blue and varying star-like shapes.  Yet it is impossible to model each account separately so they would have been grouped together using the best possible description of them as a whole.

Transactional fraud models need not be so tightly bound by this requirement, though the extra flexibility that this allows is often over-looked by analysts too set in the traditional ways.

Transactional Fraud Models

Many transactional fraud models take the credit approach and ask ’how much does this transaction look like a typical fraud transaction?’.  In other words, they start by separating all transactions into ‘fraud’ and ‘non fraud’ groups, identifying a ‘typical’ fraud transaction and then comparing each new transaction to that template.

However, rather than only asking the question ’how much does this look like a typical fraud transaction?’, a fraud model can also ask ’how much does this look like this cardholder’s typical transaction?’.

A transactional fraud model does not need to group customers or transactions together to get a view of the future, it simply needs to identify a transaction that does not meet a specific customer’s established spend pattern.  Assume a typical fraud case involves six transactions in a day, each of a value between €50 and €500 and with the majority of them occurring in electronic stores.  A credit-style model might create an alert whenever a card received its sixth transaction in a day totaling at least €300 or when it received its third transaction from an electronic store.  However, if it was known that the cardholder in question had not previously used their card more than twice in a single day and had never bought goods at any of the stores visited, that same alert might have been triggered earlier and been attached to a higher probability of fraud.

A large percentage of genuine spend on a credit cards is recurring; that is to say it happens at the same merchants month in and month out.  In a project on this subject, I found that an average of 50% of genuine transactions occurred at merchants that the cardholder had visited at least once in the previous six months (that number doesn’t drop much when one uses only the previous three months).  Some merchant categories are more susceptible to repeat purchases than others but this can be catered for during the modeling process.  For example you probably buy your groceries at one of three or four stores every week but you might frequently try a new restaurant.

The majority of high value fraud is removed from the customer by time and geography.  A card might be ’skimmed’ at a restaurant in London but that data might then be emailed to America or Asia where, a month later, it is converted into a new card to be used by a fraudster.  This means that fraudsters seldom know the genuine customer’s spend history and so matching their fraudulent spend to the established patterns is nearly impossible.  In the same project, over 95% of fraud occurred at merchants that the genuine cardholder had not visited in the previous six months.  Simply applying a binary cut-off based on whether the merchant in questions was a regular merchant would lead to a near doubling of hit rates from the existing rule set.

Maintaining Customer Histories

The standard approach to implementing a customer-specific history would be as illustrated above.  In the live environment new transactions are compared to the historical record and are flagged if the merchant is new or, in more sophisticated cases, if the transaction value exceeds merchant-level cut-offs.  The fact that this is outside of history is used as a prioritisation with other fraud rules to create alerts.  Then later, in a batch run, the history is updated with the data relating to new merchants and changes to merchant-level patterns.  If only a specific period worth of data is stored, then older data is dropped-off at this stage.  This is commonly done to improve response times with three to six months worth of data usually being enough.

Customer-specific patterns like this are not enough to indicate fraud but, when used in conjunction with an existing rule set in this way they can add significant value.

There are of course some downsides to this approach, primarily the amount of data that needs to be stored and accessed.  This is particularly true if your fraud rules are triggered during the authorisations process.  In these cases it may be necessary to sacrifice fraud risk for performance by using only basic rules in the authorizations system followed by the full rule set in the reactionary fraud detection system.  Most card issuers follow this sort of approach where the key goal of authorisations is good customer service through fast turn-around times rather than fraud prevention.

The amount of data stored and accessed should be matched to each issuer’s data processing capabilities.  As mentioned earlier, simply accessing a rolling list of previously visited merchants can double the hit rate of existing rules and is not a data-intensive process.  Including average values, GIS or other value-added data will surely improve the rule hit rates even further but will do so with added processing costs.

The typical implementation would look like the diagram below:

In this set-up, customer history is not queried live but is rather used to update a series of specific fields such as customer parameters and an exception file.  The customer parameters would be related to the value of spend typical to any one customer and could be updated daily or weekly – even monthly updates will be alright if sufficient leeway is included when these are calculated.  An exception file will include specific customers to whom the high risk fraud rules should not apply.  This is usually done to allow frequent high risk spenders or frequent users of high risk merchant types – often casinos – to spend without continuously hitting fraud rules.

Once an authorization decision has been made, that data is passed into the offline environment where it passes through a series of fraud rules and sometimes a fraud score.  It is in this environment that the most value can be attained from the addition of a customer-specific history.  Because this is an offline environment, there is more time to query larger data sets and to use that information to prioritise contact strategies which should always include the use of SMS alerts as described here.

Here the fact that a transaction has fallen outside of the historical norm will be used as an input into other rules.  For example, if there have been more than three transactions on an account in a day and at least two of those were at new merchants, a phone call is queued.

Read Full Post »

Managing transactional fraud is like searching for a needle in a haystack.  Except the needle is moving and the haystack is growing!  Faced with an environment as complex and daunting as this, banks invest large amounts in increasingly sophisticated fraud detection systems.  These systems are typically built around a statistical model and aim to identify those transactions which most closely resemble previous fraudulent transactions.  These systems seek to increase the efficiency and effectiveness of the system by increasing the probability that each customer contact will detect and confirm fraudulent spend while simultaneously increasing the total number of fraudulent transactions detected.

Investment in large transactional fraud systems is justified by the ever-increasing cost of fraud losses.  However, the idea that they alone can solve the problem is based on an old paradigm.

Traditionally, communicating directly with customers was expensive and time-consuming.  To confirm fraudulent transactions banks needed to contact customers telephonically.  Since it was not financially viable for banks to contact every customer to confirm every transaction, they invested in systems and analysts that could screen the mass of transactions and identify only those transactions likely enough to be fraudulent so as to warrant the cost of a confirmatory phone call.  This was true even while the configuration of those systems necessarily resulted in fraudulent transactions being ‘missed’.  The companies that produced these transactional fraud detection systems, meanwhile, focused their efforts on making them ever better at calculating the probability of any one transaction being fraudulent.

But the key underpinnings of this paradigm – namely that staff and communication are both expensive – are no longer true.  Once the old paradigm is abandoned, it is possible to find significant value in simple and cheap solutions like SMS transactional alerts.

An SMS transactional alert is an informative SMS that is automatically generated whenever a transaction meeting pre-set criteria is processed on a credit card.  These SMS alerts typically include some basic information about the transaction and ask customers to phone or text the bank in the event of that transaction having not been originated by themselves.

SMS alerts are inspired by a new fraud management paradigm, one that is underpinned by the assumption that ‘staff’ can be free and that communication is very cheap.

SMS alerts clearly don’t change the direct costs of employing staff.  Rather, they transfer the workload of screening alerts from paid employees to unpaid customers.  If the bank sends an SMS alert to a customer, it is that customer who takes the time and effort to validate the transaction.  So, where once a large team of employees was needed to analyse transactions and to contact customers to confirm suspected frauds, it is now possible to screen almost all transactions with a small team of employees and a very large ‘team’ of customers.

It was the high cost of communicating with customers that made it essential for suspicious transactions to be manually screened and reduced before customers were contacted.  But, none of this is necessary now that banks can contact customers instantaneously and very cheaply through SMSes.

As a fraud prevention tool, SMSes do not preclude the need for traditional fraud management tools.  Rather, they free up manual resources and allow staff to focus immediately on the highest risk as identified by these systems.

When implementing SMS alerts, it is important to avoid two common mistakes that are often made when old paradigm thinking is allowed to persist.  Customers should not be charged for the service – though in some markets the practice does exist – and the triggers should be easily understood.

The value of an SMS alert system increases with its coverage, not with its efficiency.  Every SMS alert saves more money than it costs.  Therefore, the bank saves more money as each additional customer is enrolled in the programme.  By trying to recover the running costs directly from its customers, a bank limits the scope of its programme and, in so doing, limits its savings.  Though, in some markets banks have successfully charged for the service without major reductions in customer take-up rates.

Alerts should be sent for all transactions over a nominal value-based trigger – either enforced or customer-selected.  It may be more efficient to send alerts based on calculated fraud rules but this, again, is false economy.  Because staff are free and communication is cheap, it is now cheaper to send alerts for all transactions than it is to risk missing a fraud.  It is also preferable to meet customer expectations by generating alerts when – and only when – they are expected.

These alerts are not just a cheap way to limit fraud, they’re also a very effective way to do so.  When used fraudulently, an account that receives SMS alerts is likely to suffer losses fifty to seventy percent lower than those experienced by a similar account not receiving SMS alerts.

The benefits are not restricted to fraud savings either – customers value SMS alerts.  An SMS alert programme is therefore a win-win offering that reduces fraud losses while improving customer service.  The second non-financial benefit is an improvement in customer contact data.  Because customers expect and appreciate SMS alerts, they quickly become aware of any breakdown in communication between the bank and themselves.  And, because they appreciate these alerts, when they become aware of these broken communication lines they are more likely to pro-actively contact the bank to update their contact details.  Since all functions of the bank can access this information, they too benefit from better contact rates for their strategies.

In summary, a bank with a good SMS alert programme is likely to have lower fraud losses, lower fraud operational costs, happier customers and better customer contact details.

Read Full Post »