“Moving fast and breaking things” can be a slogan to embrace, but can also be a valid criticism of startups at the leading edge of innovation. When it comes to Fintech and regulators, friction is natural. Navigating regulation and risk management when creating new financial products is something all successful Fintech companies and entrepreneurs have balanced over the years. Even in PayPal’s successful early days, they struggled to contain credit card chargebacks and money laundering. They endured numerous lawsuits and regulatory disputes in their pre-2002 IPO days.

Early stage entrepreneurs seeking growth often take an MVP approach to compliance - let’s do “what’s required” and nothing more. If a company complies with the letter of all of the rules around CIP, KYC, BSA and other regulatory requirements, they could reasonably stake the claim of having a “culture of compliance” while simultaneously having some of the worst outcomes when it comes to stopping financial crimes and fraud. 

Over-indexing on “what’s required” as opposed to “what’s smart” can lead to high fraud and credit losses, high operational costs and reduced customer lifetime value. Without experience in the space, it can be hard to know where additional investment on risk is warranted.

Below is a framework to guide risk teams on where to focus on “being smart” versus simply doing “what’s required.”

APPLICATION FUNNEL

Incorporating a risk-based determination of identity at onboarding is the smart approach to designing the application funnel. 

The CIP portions of the Bank Secrecy Act outline the requirements to make a risk-based determination of identity based on name, date of birth, address and SSN. 

The intent is a comprehensive assessment of identity.

But, we often see companies “comply” with CIP by doing a check the box exercise of simply matching identity data on the application against a database of information. 

There’s a few problems with this:

• Incorrect KYC vendor data - KYC vendor data is usually acquired from data licensing agreements from credit bureaus in the form of “credit header data” or other third-party sources. This form of identity data often has incorrect identity data (e.g. identity records for “Hello Kitty,”  “John Doe,” and “Spongebob Squarepants” exist in these sources).
  
  
• There’s no verification the applicant controls the identity - IP address, device data, phone, email, and other signals can signal the control of the application’s identity. There’s nothing in CIP rules that state you must collect and validate a phone number or email address when issuing financial products in an online environment, but it would be an oversight to not do this.
  
  
• Ineffective in assessing identity - It’s often too coarse of a way to make account-opening decisions, and results in either too many false positive declines, or an excessive amount of customer friction in manual review.

The intent of CIP is to form a reasonable belief about the true identity of the applicant to prevent financial crimes. Simply matching identity data with database information at onboarding often leads to product gaps that are exploited by fraudsters and results in scaled losses to application fraud.  

DECISION POLICIES

Smart decision policies consider both risk and product management efforts in addition to compliance. 

Understanding allowable decisioning under the Fair Credit Reporting Act (FCRA) and Gramm Leach Bliley Act (GLBA) is table stakes in developing account opening or transaction accept/decline policies. Every innovative Fintech company has nuances particular to their business model, product, partner bank relationship, and state regulation that drives these compliance requirements. Also important to consider are the consumer as well as the fraudster experience. 

Taking an R&D approach to the consumer experience was covered in the first blog post in this series. Modeling the fraudster experience is most often missed by inexperienced operating teams without backgrounds in credit or fraud risk management. Mapping out all possible fraudster onboarding scenarios is a framework that can help an early team avoid falling into the trap of simply doing “what’s required” and not doing “what’s smart.”

TRANSACTION REVIEW

Manual review systems that go beyond basic alerts and include considerations of baseline transactions and customer lifecycle metrics are the smart approach to transaction review.

When it comes to issuing a card, bank account, or other product where funds are loaded or spent on a transactional basis, “what’s required” is establishing a formal process for reviewing transactions for suspicious activity (most of which is related to money laundering).

A minimal, “what’s required,” approach often involves manually reviewing queues of accounts for suspicious activity after transactions have occurred. These queues are typically created based on rules required under the Bank Secrecy Act related to Currency Transaction Reports (CTRs) or Suspicious Activity Reports (SARs), and include the volume of funded transactions, and systems for “alert management.”

This approach does not take into account loss events or unexpected credit losses. Loss events are a good opportunity to understand if policies or product strategy should be adjusted as part of understanding product abuse that is not captured by existing fraud or credit policies.

A smarter, more holistic approach would take into account:

• Other data points about the user that can be obtained through the entire customer lifecycle such as onboarding and application data, servicing information, login activity, and customer support systems.
  
  
• Baseline metrics on what is “normal” transaction behavior for a given product strategy and using that to calibrate what merits a manual review. 

Including Risk Ops and manual review teams as part “R&D” and part “Operations” is also recommended. When transaction monitoring is done really well, it’s viewed almost like a user experience or product management exercise to better understand behavior on a platform. This includes figuring out how to block actors, adjust policies, and inform product and risk roadmaps. 

If transaction monitoring is simply viewed in terms of an operational issue where the goal is to alert, queue, review and report as efficiently as possible, there’s usually opportunity lost at an early stage Fintech company. More value can be gained from product R&D than operational efficiency or loss prevention.

FURTHER READING

If you found this post interesting and want to take a deeper dive into the topic, we’d suggest reviewing the source document behind how financial institutions are assessed in the BSA Examination Manual. We’ve found that surprisingly few Fintech entrepreneurs even give this document a skim, use it as a reference in designing product and technical requirements, or cite it when engaging with their partner banks.

_______________________________________

SentiLink is publishing a series of articles and webinars on the craftwork of Risk in high growth startups: best practices, organizational design and hiring, benchmarks, and insights we’ve seen from the most successful Risk teams in Fintech.

This content is designed to be a helpful guide for early stage FinTech entrepreneurs and operators as they scale their startups to their first 100 employees. We would love to hear if there are specific topics you’d like us to cover.

________________________________________

Vivek Ahuja’s background in Risk at high-growth Fintech companies includes risk product management at Marqeta, credit and fraud risk management as Affirm’s head of Merchant Risk, and as the co-founder leading anti-fraud efforts at Xendit.