Introduction to Online Payments Risk Management

Chapter 1. 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.