Online Payments Risk Management

Introduction to Online Payments Risk Management

Ohad Samet

Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo

Preface

Why Was This Book Written, and Who Is It For?

Losses and fraud are as old as human society. Scams and acts of fraud were not started nor invented by the digital generation. The most widely known scam, the “Nigerian Prince” or “Advance Fee” scam, luring victims to pay large sums in exchange for a big and never-arriving payout, is not a digital invention. It is a modern variant of the “Spanish Prisoner” scam, which originated in the 19th century. In any situation involving the opportunity for gain, be it a game for chips or an actual money transfer, some people are going to try to bend the rules. They do so even when there is no way to cash out, in order to get ahead and maintain status if nothing else. Almost everyone cheats; some of us are professionals.

As more and more financial activity goes online, the potential payout becomes larger. It was once only possible to steal a credit card. Now you can lend money, refinance your loan, or start a new business online.

Increasingly, consumers go shopping online. 2012’s Cyber Monday saw sales of almost $1.5 billion, the biggest in history. Consumers have their lives online on Facebook and Twitter. Identities are easy to steal, replicate, and invent; Facebook reports that about 9% of its profiles are fake. On top of all that, consumer activity creates enormous amounts of data that require novel techniques for simple searches, let alone understanding who’s real and who isn’t, who’s a fraudster and who’s telling the truth. When operating a financial services business you are faced not only with fraud, but with other causes for losses driven by multiple factors: credit default, misunderstandings, bad operational procedures, and more. I realized that there needs to be a single source for a methodical and comprehensive way to find, describe, understand, and deal with these problems so that businesses could succeed online.

This book aims to be that source — to give an introduction, overview, and overarching framework for dealing with risk in online payments. The material in it has been accumulated, shaped, tested, and proven to work over several very busy years of working in various payments companies, specifically in risk management and fraud prevention for payments, as well as consulting and discussing with many others. It aims to spark a discussion around the practice of risk management in payments in particular and eCommerce in general, as well as give the layout of what one should think about when approaching this vast field. It brings together data, organization, technology, UX, product, and other insights to present a blueprint for the best-possible loss and risk management organization in a rapidly changing digital environment, from a one-person task force to dozens of agents and analysts. It covers the essentials of the first couple of years and points toward following steps.

This book isn’t a complete step-by-step manual, as that would require thousands of pages; it is an introduction with some needed elaborations. It also skips a lot of basic knowledge that can be obtained through other sources and, therefore, isn’t always a 101-level book, although I made sure to explain every term that may be less than obvious. There is no deep discussion of machine learning, model building, frequentist vs. Bayesian statistics, or preferred packages for visualization; these topics are covered at a reasonable to extensive level in many other books, and their detailed and specific application is only required after the tools in this book have been exhausted. Neither does this book include typical application review procedures or price ranges for common data sources; the first is too specific to your system and data availability, and the second is available online using simple searches. But it will get you started and take you far along your way. More than anyone, this book is aimed at those who are tasked with starting a RMP function, whether in a small or large corporation. Veterans will find best practices that they have worked with through the years and new ideas that they may want to adopt. CFOs, COOs, and CEOs that have a RMP team reporting to them will learn more about its internals and what to expect of it, as well as some insight into how to measure its performance.

Acknowledgements

I have many people to thank for the incredible experiences I’ve had through my career — first and foremost my teams. Over the years, I’ve had the opportunity to work with, lead, and be inspired by some of the most intelligent, capable, and challenging people I’ve ever known. Together, we were able to build teams that not only delivered extraordinary value but also became a brand. As a result, many of those people are now leaders of risk, analytics, product, and operations teams in various new startups and companies.

I’d like to thank the people who have mentored and helped me through my career. There are so many who’ve inspired and helped — too many to count — but I will still try to recognize at least some of them. Saar Wilf and Shvat Shaked for starting FraudSciences and Noam Naveh for being a great trainer and manager. Denise Aptekar, Dan Levy, Rohan Mahadevan, Elena Krasnoperova, and Alyssa Cutright for their mentorship through FraudSciences’ acquisition and integration while they served as PayPal’s risk leadership team. Tel Kedar and Chandra Narayanan for being inspiring and challenging peers. My brother Yuval Samet for being a strong business partner as we started and ran Analyzd together. Sebastian Siemiatkowski, Niklas Adalberth, and Victor Jacobsson, Klarna’s founders, for being such great partners post-acquisition. And last but not least, my mentor, the late David Davidi, for his ongoing support and street smarts as I was paving my way. May he rest in peace.

Part I. Background and Theory

What Is Risk Management in Payments?

Risk management in payments is a peculiar practice. Generally, risk management is focused on the analysis and reduction of risk in various types of activities. Specifically, it regards analysis (in its simplest definition: understanding a problem by dividing it into the smaller parts it is comprised of) of those activities, identification of potential risks (from operational through regulatory ones), and the design and implementation of controls in order to identify, understand, and mitigate those risks when they occur. As such, risk management in general can be and is carried out by business and policy analysts, dealing with the best way to impose controls on operating business units. The term risk management therefore refers to many parctices, most of them unrelated to the topic of this book. For ease of typing and reference, since this book only refers to risk management for online payments, hereafter I will use the acronym RMP.

Opposing my description of risk management as a supporting corporate function, RMP is a much more holistic activity. At its best, RMP includes several activities that broaden its scope significantly compared to what standard risk management means: it includes the actual operation of controls, monitoring and reporting of performance, product management for tools used in the implementation of those controls, and much more. It is also treated differently in various organizations, from being a part of Operations, through Finance, to a unit in its own right. When we joined PayPal, risk reported to the CTO; at Klarna, to the CEO. Accordingly, the heads of RMP in these teams vary from — most commonly — customer care professionals to financial analysts or, rarely, product people. All this creates confusion as to what RMP is and what it should be in charge of, as well as how we should think about its operation and performance.

Is RMP different when done for a retailer versus a payment provider or an issuer? In essence, no: all are dealing with similar fraudsters, in a similar space, and the range of tools and customer behaviors they see are similar. There are differences, though: losses are driven by different factors, since retailers mainly deal with consumers, and payment providers deal with both. Available data are different since retailers can see browsing patterns, and issuers don’t know what the product is. Even the ability to react is different, since issuers can only block a card from transacting, but payment providers can block individual purchases or block a customer completely. Their ability to implement real-time detection, scale of available data, and tolerance to loss vary. Still, this book isn’t separating retailers, issuers, and payment providers in any meaningful way. Historically, retailers could be slightly less concerned with cutting-edge technologies, since their margins were higher and a lot of their business was done offline. As many online businesses mature and start worrying more about margins, as well as increasingly become targeted by organized fraudsters, we see more convergence in the knowledge and tools required from all types of businesses.

There are two guiding principles to the way RMP should be thought of:

RMP is a core function of a payment organization. Forcing your RMP team into Finance or Operations drives the team to look for solutions from a limited toolbox. If you are a RMP leader, you must be able to recognize and use trade-offs between rejections, losses, and cost of operation; therefore, RMP must be a separate, self-sufficient team that owns and impacts such trade-offs with input from the Sales team.

RMP is a data- and engineering-heavy activity. RMP is not a human-intensive operational team aimed at reducing losses to a minimum using manual review. A substantial percentage of losses occurs due to operational, experience, and general product issues that should be managed with appropriate tools — not improved manual decisions by an ever-growing operations team. To deal with those, RMP teams must own product and data analysis responsibilities, creating substantially more value by independently identifying and fixing issues that would not be otherwise uncovered. Furthermore, day-to-day interaction with customers, together with the instrumentation (documenting and tracking events in your system and their impact on your data in a way that allows real-time and look-back analysis of actions taken) and tracking required for reporting losses and performance, adds to the team’s competence to deal with systematic problems holistically. That also makes RMP teams the most qualified to come up with user-behavior-driven solutions that are otherwise hard to replicate.

The two guiding principles above dictate a specific structure and set of activities that should be carried out by the RMP team. This means that the team should be separate as a part of a data, analytics, or “data science” team. Setting the team up this way will not only drive higher success in controlling losses but also improve other value-creating activities that a data team can initiate and lead in your organization.

What Problem(s) Are We Trying to Solve?

Actively going after further detection and analysis of problems, trends, and phenomena in your data and system is what drives the daily improvement that supports your strategy; it is a cycle where you identify your top issues, understand what causes them, and solve them so that other issues become your top concern. However, when you go after these issues, or when you find them, you need to deal with terminology;. How will you describe your findings? What is it that you’re trying to solve?

We are trying to optimize our risk, according to our risk appetite, measured as a balance between our losses and rejections. Let’s look at it step by step:

Optimizing risk. Risk is determined by the probability of an adverse event happening (fraud chargeback, merchant going out of business, a renter’s property being trashed) multiplied by the magnitude of damage we will incur (be it financial, reputational, or other). According to our risk appetite. Determining whether we’re taking too much or too little risk is a decision owned by various officers of the company and/or external regulations — depending on the level and type of governance the company is subject to. The company’s appetite determines the amount of risk it’s willing to take; as any Head of RMP discovers, that appetite changes rapidly and is one of the major influences you must manage on a day-to-day basis. Regulation is a significant part of your risk appetite considerations. You will be regulated differently based on your business model, geography, volume, and license type. Some regulations and regulating bodies are more conservative than others, expecting certain types of decision models and style of decision making and documentation; others are open to reasonable explanations of innovative risk-taking models. All are concerned with what they understand as protecting consumers and businesses from various violations. This impacts the type of business decisions you are free to make.

Measured by losses and rejections. The company is exposed to other costs and impacts due to adverse events; a bad reputation for being fraud ridden, as eBay used to have, is a good example.

However, when dealing specifically with RMP, the most obvious numbers to track are loss rate — the total cost of chargebacks, disputes, defaults, and other penalties that we couldn’t recoup from customers — and rejections — specifically, ones that were confirmed as false positives.

Optimizing Risk with a Solution-Based Approach

A proactive approach to risk management dictates repeatedly identifying risk factors, understanding them, and acting on them. Root cause analysis is a key process that allows the understanding needed to make sure you are using the right tools for the right problems. Root cause analysis is an iterative process: first isolate a sample of problematic cases, review a few of them to analyze what happened with each of them that led to loss to identify various types of loss causes, then split the sample into smaller groups until you have several subsamples, each driven by a specific combination of reasons causing loss (or any other problem you’re trying to solve).

Root cause requires tracking an application’s lifecycle step-by-step in order to understand exactly what happened to it. For example, if the cause of the problem isn’t clear when looking at purchase details but the purchase had a dispute (I use dispute to describe customers contacting you to complain about a problem with your service, rather than talking to their bank or another third party) tied to it, you may interview the customer-care agent that dealt with it. You may track the type of emails or other messages sent to the customer to see if something got lost in translation or in delivery. You may check whether the package was actually delivered and whether the customer’s signature was collected. This kind of deep investigation provides the best hints for detecting similar cases in the future and fixing the problems that caused them.

Let’s say you have commerce activity in a few countries, and one day in August you look at your chargeback reports (a chargeback is a process that starts with a consumer disputing a credit card charge for fraud or bad service with their issuer, followed by your acquiring bank puling money from your account to compensate the consumer) and discover that you went from 0.2% in total chargeback volume to 0.4%. That’s double the number, so obviously you’re worried. What’s going on? First you’ll need to understand when the problem occurred. The fact that you got 0.4% in August doesn’t mean a lot, because chargebacks come in at different times after the purchase. So you chart a graph by purchase date and discover that the bump stems from purchases made in April. What happened in April? Looking at incoming disputes you realize that complaints about nondelivery of goods peaked for purchases that month. It turns out that one of your suppliers was late and many customers got their products later than usual. Many complained and some gave up on the deal and charged back because customer-care staff was not properly briefed to give refunds. Loss? Indeed. Fraud? Not at all.

Consider another one: you work for a payments provider and your ops team reviews purchases and suddenly they notice multiple iPod purchases. That immediately seems suspicious, so you take a look at whether there’s something connecting them. Quickly you discover that all of these purchases, although seemingly done by different people, were all done from the same IP at a computer lab at a university in Nevada. What’s more, most of the people whose identity was used don’t live anywhere close to Nevada, and it doesn’t seem like their kids go there, either. One fraud attack on an electronics retailer averted!

A coherent and consistent framework or “risk language” must be used to describe the current state of affairs of your team’s knowledge, assimilate new findings, and make sure that when a phenomenon is discussed using certain terms it is understood by everyone (analysts, modelers, developers, etc.) in a similar way. I’ve been using a relatively consistent framework through my years in RMP, and it has proven to cover most if not all phenomena while being sufficiently lightweight.

Why Talk About Loss and Not Fraud?

Fraud is a limiting definition causing us to look at the customer’s intent as the root of all loss events. That is not the case. Misunderstanding, product issues, technical and process breakdowns, and general lack of financial planning can all lead to loss events. By looking at loss, we do not limit our thinking and investigative ability (this is why I choose to not use the term friendly fraud but rather abuse to describe some loss events). Customer behavior online is impacted by so many factors: your product features, the time of year, whether they had a little too much to drink and are aimlessly browsing the Web. They are often operating without malicious intent and, sometimes, without intent at all. The fact that they are sitting in front of a computer instead of physically interacting with a live human being impacts their mindset. They may have easier access to another’s payment details at home or at work or just share a computer and not pay attention to who is logged in.

RMP domain experts must be able to understand a multidisciplinary collection of factors and processes that impact the eventual loss numbers, rather than look for malicious actions everywhere. This will also allow them to better cooperate with the revenue-creating side of your business. Losses have an impact on your margin not only by the money you lose but also as a result of the money you spend on risk activities; from direct cost for operations and data sources per purchase to investment in development of future models, risk is a cost center. Understanding that will help your team pay attention to their holistic impact on your business.

When data source usage is big, measuring overall spending on RMP activities is another important KPI (key performance indicator, the metrics you follow indicating your business’ performance) to be measured and optimized. Data cost can reach the same level as losses and often much more, as could operational expenses on review staff. While this is an important aspect of the costs, this book is basic and only deals with the loss line.

The Two Leading Approaches to the Analysis and

Optimization of Losses

Once we understand what we’re trying to achieve, we need to understand how we get there. How do we reduce the percentage of rejected customers and losses? There are two complementary approaches to this problem.

The Portfolio Approach

This approach looks at the company’s portfolio of customers top down and looks for optimizations regardless of individual customers’ behavior. This means that to reduce losses and rejections we need to provide an inflow of better customers — target safer industry segments, attract repeat consumers with lower risk profiles, etc., as well as block segments of illperforming ones. If we need a shift in losses or rejections for a market or a large merchant, we can adjust our scoring threshold (which means a change to the trade-off between rejections and losses) to accept more or fewer consumers. Accordingly, this approach supports certain types of modeling and reporting that allow it to be effectively applied. The portfolio approach is most effective when dealing with long credit times: e.g., credit card, auto, and mortgage portfolios. This is because credit trends are local, sometimes hyperlocal, and are greatly impacted by macroeconomic trends not only for new applications (when I refer to principles relevant to both consumers and merchants, I use the term application(s)) but also in existing loans’ due payments. The portfolio approach and its related modeling techniques have permeated from banking to RMP through companies like HNC/Fair Isaac and their alumni moving to PayPal, Amazon, and other large companies.

The Behavioral Approach

This approach looks at the company’s business as a discrete series of interactions with customers and aims to make the right decision in every case based on correct classification of the customer’s behavior. While there are different ways to go about doing so, they generally agree — if we have a problem with losses or rejections, we must identify trends and behaviors that drive that trend and solve its underlying reasons. This usually means case-by-case investigation and uncovering of “root causes” for losses and rejections, in an attempt to correctly classify wanted and unwanted phenomena.

Which of These Methods Works Better?

As I noted, they are complementary, with each fitting different circumstances. Both are highly effective when used correctly. The portfolio approach is especially effective when working in mature markets (where product issues and major problematic behaviors have been identified, modeled, and solved) and for dealing with macroeconomic risks (such as shifts in debt-to-income ratio due to high unemployment or targeting of a subprime population). The portfolio approach can also help guide a company’s entrance to a new market: it is easier to set standards for what are “safe” industry segments to target and mid-market merchants to partner with than to predict individual behaviors when initially entering a market.

The behavioral approach is effective and needed when you deal with highmagnitude risks (e.g., sexual predator detection in chat rooms) or in cases where behaviors can change rapidly. In RMP, a large proportion of loss cases are a result of a malicious and planned action by a prepared adversary. Those patterns change rapidly in response to your actions and any weakness you may expose, since there is clear incentive for overcoming your defenses. In addition, unlike with long-term loans such as credit lines, every purchase or merchant on-boarding (on-boarding means deciding to accept the business as your customer) is a decision point. At that point, your decision or the user’s behavior may change, allowing flexibility in response from both sides; the portfolio approach is limited at dealing with such threats. Therefore, to deal with fraud, abuse, and nascent markets, one must be able to use the behavioral approach, while for mature markets and credit decisions, you must be able to use the portfolio approach to make top-down trade-offs.

How Should We Describe and Understand Behavior?

Through our interaction with our customers (I am using consumers to indicated the individual making a purchase or a payment, merchants to indicate the providers of goods or receivers of payments, and customers to indicate both), from first encounter to termination, we see changes in the details they provide us, how they act on our website, their interaction with us through email and phone, and much more. We constantly re-evaluate our customers at any of these points to see if there are any alarming changes that require our attention. How do we make sense of them? By using them to answer three questions:

  1. Who is this? Our interaction with our customers — whether they make a purchase, start using a service, or call customer care — starts with a simple assertion of identity. There are two things to establish here:
    1. Validation: Does person X or company Y really exist? Dealing with a nonexistent entity (person or company) exposes you to multiple problems, from simple fraud (as a company, I sell products but never ship them) to money laundering. That is why companies are subject to KYC/KYB regulations (Know Your Customer/Know Your Business, a set of regulations defining the minimal set of information to collect about your customers). Still, even for unregulated companies, being able to make sure that your customer’s identity is valid and exists in the world is basic.
    2. Authorization and Authentication: Establishing that someone or something exists is one thing. The other question is whether the person currently claiming to be X or Y is indeed that person, or someone authorized by that person/company to act on their behalf. An authorized person may be a family member, a friend, or a co-worker, not necessarily the person whose details they provide — but nonetheless they need to be authenticated (have the right credentials) and authorized (have permission to use those credentials). Failing to check that exposes your system to

the use of stolen identities by both fraudsters and relatives. In addition, if you offer password-protected accounts, your accounts will be targeted for hacking (since it’s easier to steal a password for an established account than fake one). If you manage a marketplace, having one of your trusted merchants’ accounts hacked and maliciously used to sell nonexisting inventory is highly unpleasant and creates loss that’s hard to recover. While difficult, users’ needs (parents letting kids use their account, multiple employees using a single account, or MMO players buying “power leveling” services) dictate that you must be able to identify authorized and unauthorized uses of the same identity by multiple people.

  1. Can they keep their commitment? The question of financial and operational ability is the one most debated in credit modeling and less so when dealing with fraud and “classic” RMP for eCommerce. Failure to address this question exposes you to customers taking on financial commitments for extended periods of time, some of them in good will, and then defaulting. While consumers may not be getting a credit line from you, merchants essentially are. If they presell a large amount of stock and get defrauded into bankruptcy by a supplier, fail to provide adequate customer care and provide defective products, or fraudulently sell something they don’t intend to ship, you are exposed for the whole sum. Most probably you are going to pay at least some, if not all, of the proceeds to your merchant — and be left with the complaints when they disappear. You should also think of any situation in which you are effectively fronting a customer money by paying them in advance of having money in your bank account as credit granting. If you enable same-day direct bank payments without ensuring positive balance in customers’ account, you are in fact extending credit. Since customers’ ability to keep their commitment is undertreated in many RMP teams and most of the knowledge about merchant credit is from banking (and therefore not easily adjusted for online or contemporary business needs), merchant-driven losses are constantly on the rise. Looking at customers’ ability should be twofold: what they can afford now as well as what they will be able to afford in the future; whether their ability to pay is stable. This is true to consumers getting a long-term loan and also to merchants whose financial standings can deteriorate.
  2. Will they keep their commitment? Customers can be who they say they are and also capable of fulfilling on their commitments but never intend to do so. Since the online experience is not a personal one (online businesses look for scale, which is contrary to personal 1:1 communication) the psychological barrier to fraud, or just neglect to pay or communicate properly, is much lower. As a result, customers are not adverse to having late payments, false charge-backs, and other unfounded claims. Serial abusers will identify a way to reduce their liability and get away with a certain behavior and will do so repeatedly unless detected and stopped. Therefore, being able to either detect good intent or impact customers’ mindset to want to keep their commitments is another component of a RMP system.

Remember: People Make Mistakes

A lot of the loss you deal with, up to mid-double digits, can be caused by various mistakes made by employees or customers. Of course you may see cases of customers claiming to not understand something about your product as an excuse for not paying or even experience employee fraud, but more often than not there are genuine, large-scale problems in your product, experience, or operations that cause losses. Whenever you look into a loss case, you must first rule out any of those.

Your product may drive losses by the way it works. This comes into play when customers fail to understand features they are buying, or that in fact they are buying something. If your user acquisition is based on a free sample followed by automatic registration or a change of cost, some of your customers will end up being unable to pay or just uninterested in paying. These could be built into your product and be considered a cost of doing business and will be almost impossible to detect in advance.

Your customer experience can drive losses. Disputes are an example: if a consumer tries to submit a legitimate dispute about a merchant and has a hard time going through your dispute flow, you will be slapped with an unnecessary chargeback and additional fees for a case that could have ended with a refund. Another simple example is your dynamic descriptor, the text that appears next to your charge in the credit card’s statement; if that is unclear or hard to search and identify, you will see unjustified chargebacks.

Operational issues may also cause losses. Multiple problems can be caused by money movement just being complicated, but also from relying on increasingly old and malfunctioning financial systems. Corruption of the acquirer’s settlement file, the file contains the payments it captured (actually debited) for you, could lead to some payments being incorrectly allocated and appearing as losses when they’re not supposed to; the same can happen with internal accounting allocation of payment revenues. Wrong procedures in dispute handling may cause wrong settlements in either side’s favor that are inconsistent with your protection policy — driving angry merchants to not pay their fees and leave your platform — or just drive consumers to issue more chargebacks.

People makes mistakes, and that’s part of every day life in your business. Those mistakes can many times be fixed easily (by a change in procedure or text in an email) and make a big difference in your losses. Always take that into consideration when you analyze root cause, because assuming intentful actions by customers may often lead you to the wrong conclusions.

Putting the Framework to Use

Using the three questions (Who are they? Can they meet their obligations? Will they?), we can explain and describe most loss occurrences. While theoretically these questions are mutually exclusive and describe the majority of phenomena we’ll run across, we must remember that:

  1. The indicators we collect from our users will not point at one or the other in a mutually exclusive manner. Does a consumer providing slightly altered details show bad will, stolen identity, or simply privacy awareness? If a consumer tries to shop, gets rejected, and then tries again for a lower amount, is this lack of finances or abusive behavior? Even if a negative event occurred and loss has materialized, it’s often hard to distinguish what the absolutely real cause for it has been.
  2. People make mistakes. A lot of the theory and many policies assume that customers’ actions are a reaction to something (even if not rational, such as the feeling that they don’t need to pay a virtual service because it’s a victimless crime). The truth, however, is more complicated. If you do your work well, big shifts in your actual losses will be driven by major events (big new merchant introducing a completely different population, macroeconomic shifts, a new product). On a day-to-day level, though, the majority of losses will be driven by mistakes. These causes can be detected and eliminated by root cause analysis but are not covered by the above framework.

Putting aside integration issues, as discussed, customer behavior should all fit into this matrix. Most of your customers in a standard eCommerce operation will be who they say they are (own the identity they’re using) as well as have the money and the willingness to pay. They are the people shopping from work or home, providing their own payment details, and are unlikely to charge back unless there’s a huge issue with your service.

Most of the fraud you’ll see is at the other side of the spectrum:

perpetrated by fraudsters who use stolen or fake identities and do not have an intent to pay. In most cases, however, they (or rather the person who’s details they stole) will have the funds to pay — if the card they’re using doesn’t have any balance on it, their purchase won’t go through, and therefore fraudsters will not be interested in their cards; that means that any detection mechanism aimed at figuring out whether there’s money in one’s account is not going to help detect most blatant fraud.

A third example is abuse, sometimes referred to as friendly fraud. As noted previously, cases of “borrowed” identity (the person expected to pay is related to the person initiating the purchase, as in cases in which children use their parents’ card details) are not really fraud: there’s ability to pay and the identity was not stolen, but the willingness to pay is missing. This is a unique type of behavior, where the “borrower” feels that nonpayment online is a victimless crime or maybe that the use of the Internet’s semianonymity allows different behavior than when face to face (some consumers almost treat online fraud as the equivalent of stealing cash from their parents’ wallet). Fraud is about identity theft and forging details, and abusers should be treated as misguided individuals who are lax on personal standards but will behave well when reminded. A vast body of research repeatedly demonstrates how this works in real life.

As you can see, there is a vast range of behaviors for both consumers and merchants to understand and work with, and detecting them is both science and art. Being able to detect, analyze root cause, and then act on major problems and emerging trends is the core of what the RMP team should do day to day. Now that we’ve established basic terminology, we are free to discuss the topics that build on it.

Cart