Webull, a digital investing platform, was fined $4.2 million by US regulators for not having "reasonably designed" programs for anti-money laundering, identity theft prevention, and best execution. The key phrase here is "reasonably designed." Regulators didn't claim the programs were missing; they said the design was inadequate.
If you're in charge of compliance at a digital platform, this language should prompt a reevaluation of your current approach.
The Decision You Are Facing
How do you build or rebuild your AML/CFT Framework so it can be defended as reasonably designed, without compromising the speed and low-friction onboarding that your business model relies on?
There's no one-size-fits-all solution. However, there are three realistic paths, each with its own strengths and weaknesses. The sections below will help you choose the right one and identify potential pitfalls.
Key Factors That Affect Your Choice
Before choosing a path, consider these questions carefully. They influence everything that follows.
1. How fast is your onboarding, and how much of it is automated? Fully remote, high-volume account opening increases identity risk. This is where identity theft prevention and Customer Due Diligence intersect, and where weak design is exposed.
2. What does your Customer Risk Profile population look like? Customer geography, funding sources, and account behavior should shape your Customer Risk Rating model. A uniform rating for everyone is a design flaw.
3. Who owns the program? If compliance reviews outcomes but doesn't control system configuration, your documented design and your actual design can drift apart.
4. Can you evidence your decisions? Examiners will ask why a rule, threshold, or control exists. "The vendor default" is a weak answer.
5. How often does your product or customer base change? A static design on a changing business is a common route to inadequacy.
Path A: Build Around a Risk Assessment, Then Configure Controls to It
Choose this when: your product set, customer base, or funding channels are changing, or you can't currently explain why your Transaction Monitoring Rules look the way they do.
If your controls were bought or inherited before anyone mapped your actual risks, then start with an enterprise-wide risk assessment and work outward. Document inherent risk by customer type, product, geography, and delivery channel. Then tie each control to a named risk.
What drives this path: The Bank Secrecy Act (BSA) requires covered institutions to maintain an AML/CFT Framework with internal controls, independent testing, a designated compliance officer, and training. FinCEN's Customer Due Diligence (CDD) rule adds the requirement to understand the nature and purpose of customer relationships and to conduct ongoing monitoring. A risk assessment shows how these elements fit your business instead of a generic template.
Where it breaks: the assessment becomes a shelf document. If your Transaction Monitoring Rules, Customer Risk Rating logic, and escalation thresholds don't visibly change when the assessment changes, you've built paperwork, not design.
Path B: Tighten the Technology and Data Layer First
Choose this when: your risk assessment is sound, but your controls are failing at execution. Think alert backlogs, inconsistent identity verification outcomes, or monitoring that can't see across accounts.
If your policies say one thing and your systems do another, then fix the data and tooling before rewriting policy.
RegTech is useful here, but only if you treat it as part of the design, not a substitute for it. Practical checks:
- Identity verification: Does your onboarding flow detect synthetic or stolen identity indicators, or only confirm that a document looks valid? Weak identity theft prevention doesn't just create fraud losses; it lets bad actors into your platform as seemingly legitimate customers, undermining every downstream AML control.
- Monitoring coverage: Does your Name Screening and Transaction Monitoring Rules cover all products and channels, or only the original ones?
- Tuning evidence: Can you show why thresholds were set and when they were last reviewed?
- Data lineage: If a rule depends on a field that's populated inconsistently, the rule is unreliable regardless of how well it's written.
Where it breaks: automation without governance. Faster onboarding and automated decisioning are fine, but every automated decision needs an owner, a review cycle, and an escalation route to the MLRO.
Path C: Rebalance Governance and Independence
Choose this when: controls exist and technology works, but you can't demonstrate that anyone is challenging the program.
If your independent testing is thin, your compliance officer lacks authority over system changes, or training is generic, then this is your weakest point, and examiners will find it.
Concrete moves: give the compliance function sign-off on changes to monitoring and onboarding logic; scope independent testing to the controls that carry your highest risks, not just the easiest to test; and track remediation items to closure with dates and owners.
Where it breaks: governance theater. Committees that meet but don't change anything don't make a program reasonably designed.
Balancing Compliance and Operational Efficiency
The tension is real, but it's often overstated. Friction isn't the same as control. A well-designed program applies heavier checks where risk is higher and lighter ones where it isn't. Risk-based onboarding paths, tiered review queues, and targeted Ongoing Due Diligence let you protect conversion on low-risk customers while concentrating effort where it counts. What you can't do is remove controls to hit a speed target and call it efficiency.
Summary Matrix
| Path A: Risk Assessment First | Path B: Technology and Data First | Path C: Governance First | |
|---|---|---|---|
| Pick it if | Business is changing; controls aren't tied to named risks | Policy is sound but execution fails | Controls work but no one challenges them |
| Primary driver | BSA program requirements; FinCEN CDD rule | Identity theft prevention and monitoring coverage | Independent testing and compliance officer authority |
| First action | Enterprise-wide risk assessment mapped to controls | Audit identity verification, monitoring coverage, and data quality | Reset change-approval rights and testing scope |
| Common failure | Assessment never updates controls | Automation without ownership | Oversight without consequences |
Most platforms need elements of all three, but you should sequence them. If you can't explain your risks, start with A. If you can explain them but can't evidence execution, start with B. If both hold but no one's testing them, start with C.
The Webull penalty is a reminder that regulators judge design, not intent. Make sure yours is one you can defend line by line.
