Building vs. Buying Financial Compliance Software

Preamble

Due to the serious nature of staying compliant and the vigilance required to continuously fight fraud and financial crime, many organizations face the challenge of deciding how they should stand up their risk and compliance programs. 

This guide will present you with a case study of a build vs. buy decision and the 10 key questions to ask yourself to make the best possible decision for your organization when it comes to choosing between building an in-house solution or buying a B2B decisioning platform. 

This piece was jointly written by: 

• Ondorse Co-Founder, Aymeric Boëlle. Before founding Ondorse, Aymeric was a financial institution regulation and enforcement lawyer in the U.S., the U.K. and France, with 10 years of experience advising leading financial institutions and working with regulators globally. Disclaimer: Ondorse is a B2B decisioning platform.

• Former Head of Compliance at Qonto, Jean-Eloi Rateau. Before joining Qonto, Jean-Eloi worked at the French Financial Market Authority (”AMF”) and worked in risk and compliance-related functions at BPCE and Lemon Way. 

Introduction

Financial institutions, marketplaces, insurance companies, crypto exchanges, gaming sites and many more are seriously exposed to fraud in addition to being subject to compliance requirements. 

Traditionally, these organizations need ten or more different solutions to do the following things: 

• Retrieve data,

• Verify their user’s identity,

• Check their ID and supporting documentation,

• Ensure users are not politically exposed persons or on sanction lists, 

• Assess fraud risk,

• Authenticate them on subsequent visits,

• Perform ongoing watchlist monitoring, 

• Manage investigations and report suspicious activities. 

Spreadsheets aren't enough!

Until recently, a spreadsheet was enough to perform compliance and fraud verifications on users. But now, the challenge is two-fold: regulations are getting more complex, and fraud is becoming more sophisticated. This means that it becomes vital for organizations to adapt their compliance stack to their specific activity and risks. Yet, few manage to do it. 

Because compliance operations are traditionally labor-intensive, they are not only expensive but also high-risk: more manual work leads to more errors, which requires even more manual work... and a vicious cycle is created as compliance debt builds up. Further, manual tasks on all customers entail less time for agents to focus on high-risk users. 

This approach to manually onboard users tends to work for organizations that onboard fewer than 500 new customers every year. Beyond that number, organizations tend to struggle and look for an alternative because it is complex, inefficient, expensive, and risky. In short, it just simply doesn’t work at scale. 

Why now?

• While finance is shifting towards real-time data and processes, issues related to manual identity verifications and decisions have been holding back the fintech space, particularly in the B2B field. 

• Financial crime is a growing concern for governments and regulatory authorities as €200 billion in criminal funds circulate every year in Europe. Yet, barely 1% is seized every year, according to Europol.

• More than 80% of the criminal networks active in the E.U. use legal business structures for their criminal activities. 

• The fintech space is mature enough to be out of regulatory sandbox as enforcement agencies issued $10.4 billion in regulatory fines to financial institutions in 2020, a year-on-year increase of 26% by value and 141% by volume. 

• The use of financial services online and in self-service has taken off for businesses, especially in the post-Covid world. 

Organizations struggle with the six or more different tools they have to interpret. A B2B decisioning platform is required for them to scale. 

What options for organizations?

Organizations are looking at either building or buying a B2B decisioning platform that orchestrates all the sources they need in one easy-to-use product. 

If you believe that a purchased solution won’t offer you the customization or flexibility you need, or because having something proprietary is a cultural preference for your organization. 

Or if you believe it is both costly and risky to devote engineering resources to a fraud and AML solution because this means that resources are being diverted away from your core product. 

In this guide, we define what a B2B decisioning platform is, we explore how Qonto navigated the build vs buy issue through a case study and we highlight the 10 key questions a compliance lead should ask itself when making this decision. 

What is a B2B Decisioning Platform?

A B2B decisioning platform (”BDP”) helps your organization make informed decisions on your users and meet regulatory requirements regarding customer knowledge. There are three main components to a BDP: 

Build vs. Buy: The Qonto Use Case

At Qonto, there is a strong culture of focusing on the company’s core business: making the daily banking life of entrepreneurs easy. As a result, whenever there is a robust external solution enabling product and tech teams to focus their effort on re-inventing business financial services, Qonto will lean towards buying such a solution - rather than building it. 

However, when Qonto needed to choose between building or buying our compliance system, there wasn’t a single provider offering an end-to-end compliance platform that efficiently centralized all our required features. Thus, Qonto decided to build it. 

We then figured out pretty soon how key compliance features were for the success of Qonto. It basically: 

1. Conditioned the obtention of Qonto’s license and the relationship with the French banking regulator; 

2. Directly impacted Qonto customers’ journey and their conversion/ churn rates; and 

3. Significantly influenced the workload of Qonto’s operation and compliance teams. 

As a result, we then decided to dedicate significant resources at the outset to make things right. 

The challenges Qonto faced

Building a compliance MVP to enable Qonto to start operating as a regulated fintech was a significant technological and regulatory challenge. It involved building the following features from scratch: 

• A real-time risk scoring engine of customers taking into account multiple criteria which needed to evolve regularly. 

• An efficient way of retrieving and storing exhaustive company data on Qonto’s customers. Having customers from various countries and legal forms implied integrating multiple data sources. 

• Efficient tools to verify the identity of our customers, their shareholders and the people acting on their behalf (altogether “stakeholder”). 

• Screening of customers and stakeholders against sanction lists. 

• A back office enabling compliance and operation teams to perform controls and verifications that included: 

  • Workflows specifically built for compliance and operations that minimize customer disruption. 

  • Processes enabling operations to escalate critical cases to the compliance department. 

  • Audit trails of controls/verification for internal control purposes. 

  • Centralized and exhaustive customer profiles ensuring efficient and documented fraud/compliance analysis. 

The associated costs

It took Qonto approximately 8 months overall to build a MVP meeting the minimum requirements for a payment institution license: 

• As Head of Compliance 70% of my time was then dedicated to reviewing regulatory requirements and design features with the product team. 

• Within the product team, compliance features required an average of 1.5 FTE product managers full-time. 

• During that period, the implementation of compliance features required almost 25% of the time of the tech team, mobilizing back-end, front-end, and data engineers. 

After that initial period, compliance features also required ongoing resources in order to be maintained, improved and transformed: 

• One compliance FTE was dedicated to compliance features. 

• Tech and product teams kept working intensively on building additional compliance features for another year, in an attempt to improve and scale the system. 

What are the key learnings?

In retrospect, the benefits of building a tool internally were the following at Qonto: 

• A BDP tailored to our product offering and customer profile risk. 

• Qonto was OK managing updates and improvements to our MVP internally. 

However, we encountered a few hurdles along the way: 

• We had to divert the tech teams from working on the core banking product to work on low-added-value tasks such as maintaining and integrating several APIs. 

• Maintaining the internal tool required ongoing resources as regulatory requirements evolved rapidly over time and because our customer base quickly grew. 

• We would have wished to have quicker access to advanced technology and new BDP features, as it was not possible to update rules, decision trees or workflows without intervention from the tech team. 

• Finally, Qonto’s operations quickly expanded to other countries requiring even more work from our tech team as we did not have custom and automated workflows, which would have brought tremendous value when opening new countries. 

Retrospectively, Qonto would have saved a significant amount of resources and time if we had been able to buy a BDP including the following key features: 

• Integration of multiple company data sources covering several countries and legal forms

• Centralization of various compliance tools, preventing us from: 

  • Interfacing them with our database; 

  • Having to connect to multiple platforms to perform compliance controls 

• Case management: 

  • Gathering information about our customers; 

  • Enabling escalation; 

  • Offering a robust audit trail.

A Build vs. Buy Decision Framework

We list the 10 most important questions you should ask yourself and your organization when deciding between buying or building a B2B decisioning platform. We highlight the various challenges that can help you decide which one is best for you. 

1. What is the workload of my organization regarding onboarding of new users? 

Are you onboarding less than 5-10 customers a week and using 1 or 2 data sources to verify them? You may be able to manage onboarding flows with manual processes and some in-house automation. This may be the case if you rely more heavily on in-person communication for account opening. 

Are you managing two or more different sources, such as id. verification, watchlist screening, business data, and/or do you onboard more than 500 customers per year? You will most likely need a B2B decisioning platform, as these various data sources don’t easily interconnect and don’t generate standardized types of signals, and you need to automate part of your verification workflow. 

2. What’s your ideal risk, fraud and compliance stack to verify users ? 

Establish whether you will need more complex features such as a four-eye review spread across two different lines of defense or a log system enabling you to ensure and prove appropriate due diligence measures have been carried out in subsequent audits. Does my team need to be able to build their own rule? Do I need a queue process? What about alerts? How will data feed into my other systems, CRM, back office, and external financial services platform? If you have answered yes to one or more of these questions, you most likely need a complex solution and will look at either “building a startup within your company” or buying from vendors focused on this specific problem. 

3. Is the tech roadmap of my core product full? 

Building a BDP requires a stronger commitment from your engineering and product management resources than buying a solution. It might compete with other priorities in the roadmap. Answering questions on how critical it is from an internal resources perspective and whether a third-party platform could bring a similar value with less impact is important. 

4. Am I already exposed to fraud and AML risks? 

Building a solution from scratch will require, in the beginning, significant time and effort from your team vs. onboarding them on a new platform. You will need to get the right team aboard, have them define product specificities, plan the development of the program, and test performance once complete. 

This could mean you have to hold off on launch or slow down the pace, or you may have to operate with inadequate protection. Whether an in-house solution design to your specific needs is worth the risks attached to a lengthy project is a consideration for your decision. 

5. What fits best within my budget?

There are several costs associated with building, which can add up quickly. First, there’s the actual time and work investment to build. Then, there is the technical cost of maintaining your system. This encompasses the overhead of needing software engineers to step in and update the source code every time one API of your compliance and fraud stack changes. 

For example, here is the cost of a building project at a leading B2B fintech. 

Note: The above does not include the cost of maintaining and enhancing the tool over time. Source: Salaries are based on Gorgias salary and equity calculator + Deel employment cost calculator. 

How do these costs compare to a B2B decision SaaS solution, and how do they scale over time are questions to consider. 

6. Will my solution improve in performance and efficiency over time? 

The nature of compliance and fraud is that it is rapidly changing, with regulations being added or updated regularly and new fraud schemes quickly surfacing. A BDP platform must be flexible enough to adapt and frequently be upgraded. 

Evaluating whether your organization is committed to maintaining and updating an internal build or that your third-party vendor is flexible and knowledgeable enough to understand and accommodate these needs is a key criterion in your decision process. 

7. How configurable will my solution be? 

A BDP platform needs to be configured specifically to accommodate your business use case over time. New data sets need to be added, or new rules need to be configured. How these adjustments will be made is a consideration. Do you need engineering resources to adjust workflow or add data points? Is there some form of no-code or low-code configurability in the platform that allows non-technical users to manage some of the rules and flows? While internal builds might appear more flexible due to the full ownership of the configuration, the most recent third-party solutions increasingly take a low-code / no-code approach to configurability. 

8. How will my solution take into account regulatory changes?

A BDP must adapt to always changing regulatory requirements, especially if you operate in more than one jurisdiction. How will your organization maintain knowledge of regulatory evolutions and transcribe them into your platform configuration? For example, how would new documentary requirements be translated into functional requirements? Which data integration will be required, and how would rules and risk scores be updated? A single regulatory change can translate into a more complex configuration problem. 

9. Do I know how my peers operate? 

How are you informed of best practices in compliance both from a regulatory and process perspective? New AML risk? Fraud model? Issues with data sources? Your B2B decisioning platform will ideally reflect the answer to these questions. Understanding how a third-party vendor/partner or strong internal processes can help you and your team improve over time is key.

10. Do I operate in more than one jurisdiction? 

Rules and regulations for compliance are specific to the region a business operates within. Because of this, it can be difficult to keep track of all the regulations that apply and have tailored workflows to your jurisdictions. Further, crossing borders often means adding new data sources to manage, maintain and orchestrate. Is your solution flexible enough to adapt to new workflows and data sources and run them in parallel?