How Compliance in a Fintech Actually Gets Built
FX & Float Memo #6
Compliance is consistently misclassified as a function in a fintech. It is designed similarly to a legal function and is designed to be a gatekeeper. Neither of these gives the correct frame for looking at compliance. Compliance in payments should be looked at like operational infrastructure, something that is foundational and consequential, like the payment rails themselves.
How you build compliance in the early years determines what you can scale later. The right way is to build compliance into the product from the start. Otherwise, it will need to be rebuilt again as soon as you hit scale.
What most people believe
The common assumption is that compliance is a people problem. Hire a good Chief Compliance Officer, get a team underneath them, and the function will run smoothly. The CCO knows the regulations, and the team does the processing.
This is what compliance looks like from the outside. From the inside, it’s very different.
Compliance in a fintech is a combination of people, technology, and processes, each of which has to be deliberately designed and built. The CCO cannot do much without a KYC system for new accounts. The KYC system cannot do much without a robust transaction monitoring system. The transaction monitoring system cannot do much without a sanctions screening engine to identify restricted counterparties in real time. These are part of a single stack, with each layer depending on the one below it.
The Compliance Stack
Layer 1: KYC and KYB
Know Your Customer (KYC) and Know Your Business (KYB) are the starting points of the compliance stack. Before any customer can transact with a fintech, it needs to verify their identity.
KYC means ID verification, liveness checks, and a database match against government watchlists. Solutions for these are now available off the shelf. Vendors like Jumio, Onfido, and Persona provide API access for document scanning and facial recognition. A well-built consumer KYC flow takes under five minutes and requires no human review for most applicants.
However, for KYB, the solution is not seamless. KYB requires collecting and verifying entity formation documents, understanding the ownership structure, identifying the Ultimate Beneficial Owners who own more than 25% of the entity, and running each UBO through the same checks as an individual consumer. For a simple company with two shareholders, this is manageable. For a holding company with subsidiaries across three jurisdictions, it can take weeks.
The vendor landscape for KYB is also less mature than for KYC. Providers like Middesk, Moody’s and Kompany offer business verification, but the data quality varies significantly by country. Complex structures require extensive manual review to verify submitted documents.
The build-vs-buy decision for this layer is straightforward: buy the solution and build the workflow logic. The rules of when to auto-approve, when to flag for manual review, and when to auto-reject are specific to the company’s risk appetite and regulatory obligations.
Layer 2: Sanctions screening
Sanctions screening checks every customer and counterparty against lists of restricted individuals, entities and jurisdictions. The primary repositories of sanctions lists are OFAC and the UN Security Council. A fintech cannot transact with anyone covered in these lists, and a failure to comply attracts heavy penalties.
Sanctions screening solutions are quite mature. Providers such as Dow Jones, LexisNexis, and ComplyAdvantage maintain up-to-date watchlists and offer API access for real-time screening. When a transaction is submitted for review, it is screened, and results are returned in milliseconds.
The operational challenge here lies in managing the false positives. Watchlist matching is imprecise by design because the lists contain names that are common. The compliance team has to review each flag and determine whether it is a true match or a false positive. At low volumes, this is manageable. At scale, a false positive rate of even 1% means thousands of manual reviews per day. Building a workflow that triages these flags efficiently and routes them to the right reviewer is as important as the screening technology itself.
Layer 3: Transaction monitoring
A transaction monitoring system reviews every transaction after onboarding for patterns that might indicate money laundering, fraud, or terrorist financing.
The simplest version of implementing transaction monitoring is rule-based, i.e. any transaction above a certain threshold, any customer who sends more than a certain amount in a given period, or any payment to a high-risk jurisdiction is flagged. These rules are quick to build but also easy to game. They generate significantly higher false positives.
The more sophisticated version uses machine learning models trained on historical transaction data to identify behaviour that is anomalous relative to a customer’s established pattern. A customer who typically sends $2,000 per month suddenly sending $50,000 to a new counterparty in a new country is an anomaly. A rule-based system may or may not catch this depending on where the threshold is set. A behavioural model will flag it because it deviates from the customer’s baseline.
Most early-stage fintechs start with rule-based monitoring because it is faster to build. The problem is that rule-based systems produce alert volumes the compliance team cannot keep up with, and they miss sophisticated patterns operating just below the rule thresholds. Moving to a more sophisticated model requires clean transaction data, which takes time to accumulate, and data science capability, which most compliance teams do not hire for.
The build-vs-buy decision here is more complex than at the KYC layer. Vendors like Featurespace, NICE Actimize, and Sardine offer transaction monitoring platforms. But configuring these for a specific business model and customer population requires significant work. A remittance company and a B2B payments platform have very different risk profiles and require vastly different configurations, even when using the same vendor.
Layer 4: Suspicious Activity Reporting
When the transaction monitoring flags a transaction, and the compliance team cannot rule it out as a false positive, the company has an obligation to file a SAR (Suspicious Activity Report). In the US, it is filed with the FinCEN; in the UK, with the National Crime Agency; and in India, with FIU-IND.
SAR filing requires a judgement call on whether there is reasonable suspicion of financial crime. Filing too broadly wastes regulatory resources, and filing too conservatively is a regulatory violation. The threshold is deliberately kept vague, implying that the decision depends on the CCO’s experience and judgement.
The process around SAR filing has to be airtight. The investigation must be documented, and the decision to file or not must be clearly recorded. And critically, the customer cannot be informed that a SAR has been filed against them. Tipping off a customer is a criminal offence in most jurisdictions.
This process is complex. Managing it with a spreadsheet and a shared inbox fails at any meaningful scale. A proper case management system that can track investigations, store evidence, record decisions, and manage filing deadlines is the minimum requirement.
Layer 5: Regulatory reporting
Beyond SARs, payments companies have ongoing regulatory reporting obligations. Some of them are Currency Transaction Reports for cash transactions above certain thresholds, cross-border transaction reports, periodic attestations about the effectiveness of the compliance programme, and responses to information requests.
This layer is the least glamorous and the most frequently neglected. It is also the layer where regulators most easily find deficiencies. A company with sophisticated monitoring but poor regulatory reporting will still fail an examination.
Why do most fintechs underinvest
The compliance stack described above takes time and money to build. At the seed and early Series A stage, most fintechs build the minimum required to obtain a licence and launch: a basic KYC flow, a simple sanctions screening integration, and some manually reviewed transaction monitoring rules. This makes sense when the priority is time-to-market.
The problem is that “minimum to launch” becomes “permanent state” at too many companies. While headcount grows, the compliance team’s tooling does not keep pace. Manual processes set up at a scale of 1,000 customers become bottlenecks at 50,000 customers.
The trigger for investment is usually external, when a regulator flags deficiencies or a banking partner demands evidence of a robust compliance programme before renewing the relationship. These external triggers then force the investment that should have been made earlier, often at higher cost and under time pressure.
What most companies don’t realise is that underinvestment in the compliance stack surfaces directly in customer experience, banking partner relationships, and eventually, revenue. Memo #7 will cover the full cost of inadequate compliance.
What this means
Compliance, as a function, is widely misunderstood in fintech. It is not a function to translate the regulations and tell what can and cannot be done. It is a critical operational muscle the company needs to serve customers, move money, and partner with banks.
This has three consequences.
First, the GTM playbook determines the compliance architecture, as covered in Memo #4. A self-serve platform needs automated KYC to process thousands of applications without human review. An enterprise sales model needs bespoke onboarding flows and dedicated compliance handling for each client. A marketplace partnership model needs compliance frameworks that operate at the platform level rather than at the individual customer level. The wrong compliance architecture for your GTM model is as expensive as building the wrong product.
Second, compliance friction is a direct cause of churn, as covered in Memo #2. Customers who are placed on hold with no communication, or who wait weeks for a review decision, will leave. The quality of the compliance experience is a product decision, and it should be measured as such.
Third, the cost of fixing the underinvestment continues to grow with scale. A compliance stack that is adequate for 10,000 customers will break at 100,000 customers. Rebuilding it with the regulator or a banking partner closely watching over it, under a strict deadline, and keeping the product live is the most expensive way to rebuild it.
Most compliance problems are product and infrastructure problems, and compliance takes the blame. The right stack is required for the function to do what it is supposed to – let the business grow without breaking.