The Question at Hand
Your compliance team is evaluating a transaction monitoring platform. The vendor demo looks polished, the features meet your requirements, and the price is reasonable. But here's the critical question: who on your team can actually validate what this platform does?
The European Banking Authority's 2025 Opinion on Money Laundering and Terrorist Financing Risks highlights a significant issue: 70% of supervisors see ML/TF risks rising in the EU financial sector, with poorly implemented regtech contributing to the problem. The EBA points to "inadequate in-house expertise, poor governance, and insufficient oversight" as major barriers to effective regtech deployment.
This raises a strategic question for risk managers: should you build internal regtech expertise, or rely on vendor support and external consultants?
The Case for Building In-House Regtech Capability
If you're deploying tools that support regulatory obligations, you need people who understand both the regulation and the technology. Many compliance leaders argue this is essential.
First, vendor expertise isn't the same as organizational expertise. A vendor can explain how their platform works, but they can't confirm if it's covering your specific risk exposures. They can't validate outputs against your business model, customer base, or transaction patterns. When the EBA warns about "off-the-shelf platforms that don't reflect business-specific risks," they're describing the pitfalls of outsourcing understanding.
Second, you can't test what you don't understand. Controls testing involves more than just following a workflow. It's about assessing whether the control design is appropriate, if it's operating as intended, and if it's mitigating the intended risk. If your team can't explain how the algorithm flags suspicious transactions or why certain thresholds were set, you're not testing controls; you're documenting vendor promises.
Third, when something breaks, you need to fix it fast. Imagine a compliance team discovering their automated sanctions screening missed a high-risk counterparty because the tool's entity matching logic couldn't handle a common name variation. Without in-house understanding of the matching process, you're left waiting for vendor support while exposure accumulates.
Organizations that invest in regtech specialists typically hire individuals with backgrounds in data science, compliance analytics, or financial crime investigation. They bridge the gap between compliance and IT, translating regulatory requirements into technical specifications and ensuring outputs align with risk appetite. It's costly, but it ensures accountability.
The Case for Relying on Vendors and Consultants
The counterargument is practical: regtech expertise is a niche skill, and for many organizations, it doesn't make economic sense to staff it full-time.
Regtech vendors employ specialists who configure, tune, and optimize their platforms. They've seen implementations across numerous institutions and know what works. If you're a mid-sized bank implementing your first automated compliance monitoring system, leveraging that accumulated knowledge may be more efficient than building it internally.
Consultants offer similar benefits: they bring cross-industry perspective without the overhead of permanent staff. You can engage them for implementation, annual reviews, or when evaluating new tools. For organizations with limited compliance budgets, this flexibility is valuable.
There's also a talent challenge. Finding someone who understands both AML regulations and machine learning model validation is difficult. Even if you find them, they're expensive and may be recruited away. Smaller institutions especially struggle to compete for this talent. Relying on vendor support and periodic consulting can be a more sustainable model.
Not every regtech deployment requires deep technical expertise. If you're using a straightforward policy management platform or an evidence collection tool with transparent workflows, the governance challenge is manageable without hiring specialists. The risk arises with black-box systems making consequential decisions that you can't explain.
Where Practitioners Actually Land
Most organizations don't choose one extreme or the other. They build selective expertise based on risk exposure and tool complexity.
For high-stakes, complex systems like transaction monitoring, sanctions screening, and fraud detection, they invest in people who can validate vendor claims and interpret outputs. This might mean training a compliance analyst on SQL and basic statistical concepts or cross-training a business intelligence analyst on AML regulations.
For lower-risk tools like document repositories and workflow automation, they rely more on vendor support, with periodic external reviews to ensure the system remains fit for purpose.
The key governance practice isn't about headcount. It's about ensuring someone with appropriate expertise owns each control. That ownership includes understanding the control design, testing it regularly, and knowing when it's failing. If your team can't do that for a particular regtech tool, you've got a gap, whether you fill it with internal hires, consultants, or enhanced vendor relationships.
Our Take
You don't need a regtech specialist for every Integrated Risk Management (IRM) Platform you deploy. But if you're using technology to meet significant regulatory obligations, and nobody on your team can explain how it works or validate its outputs, you're exposed.
The EBA's warning about "inadequate in-house expertise" isn't a call to staff up indiscriminately. It's a reminder that accountability can't be outsourced. When regulators ask how you know your transaction monitoring system is effective, "the vendor said so" isn't an acceptable answer.
Start by mapping your regtech portfolio to your risk universe. Identify which tools support controls tied to high-impact risks. For those, you need demonstrable expertise, whether it's internal, external, or hybrid. For lower-stakes systems, vendor support may be sufficient, but document the rationale and review it annually.
The real governance failure isn't choosing the wrong staffing model. It's deploying technology without anyone who can tell you whether it's working.
