“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.”
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:
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.
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.”
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:
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.
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.