Why in-house builds almost always cost more, deliver less, and create long-term risk for ML/TF/PF programs, despite initial confidence
Introduction: The seductive idea that “we can build this ourselves”
Almost every MLRO has heard a variation of the same confident declaration from internal technology teams: “We can build this internally, it’s just a simple scoring tool.” It is one of the most expensive misconceptions in financial crime risk management. What starts as a seemingly simple internal development initiative inevitably expands into a sprawling, multi-year engineering effort involving UI/UX design, configuration logic for methodologies, risk and control modules, workflow rules, evidence capture, multi-entity support, role-based access, jurisdictional overlays, complex dashboard and reporting systems, data ingestion and data lineage, model governance and full audit-trail capabilities, among many other things!
What initially sounded easy, quickly becomes overwhelming. Delivery timelines slip. Additional teams are pulled in. The scope and cost grows beyond what anyone anticipated. Developers leave mid-project. Budgets inflate and the project fails to meet its original objectives or deliver any ROI.
Meanwhile, risk teams are left waiting for the tools they need to do their job. Eventually, the uncomfortable truth emerges: building a financial crime risk assessment platform in-house is not cheaper, faster, or safer – it is almost always the exact opposite.
Why IT teams underestimate the complexity
Internal engineering teams are highly capable and bring deep technical expertise. But a financial crime risk assessment platform is fundamentally different from most systems they may be accustomed to building. It requires a blend of regulatory fluency, risk methodology knowledge, typology awareness, data governance insight, domain-specific scoring models, configurable workflows, evidence-handling capabilities, multi-jurisdictional logic and regulator-grade audit trails. Even agreeing on a functional and technical solution design would take hundreds of hours of discussion to come up with something basic.
These functional and technical requirements sit far outside the normal development patterns of typical product engineering. What seems, from the outside, like a simple form and calculation engine is actually a highly specialised regulatory architecture. The complexity is hidden below the surface and it is only once the project is underway that teams realise they are building something more akin to a risk operating system than an internal tool.
The hidden costs of building in-house
Internal builds almost always underestimate the lifetime total cost of ownership. The initial development effort is only a fraction of the effort and a fraction of the cost. Once launched, the system requires continuous updates as products evolve, typologies shift, risk methodologies change, regulators release new expectations, businesses expand into new markets, new customer segments, control frameworks mature, or audit findings require remediation.
Because internal builds typically hard-code functions like methodology, weighting, scoring logic, definitions and workflows, which is a short-cut and long-term mistake, since compliance teams become reliant on software developers every time a change is needed. This dependence slows down risk management and turns IT into a bottleneck. Over time, technical debt accumulates: documentation becomes outdated or incomplete, testing frameworks degrade, core developers move on and the system becomes increasingly fragile and expensive to maintain.
The real cost is not the initial build, it is the years of infrastructure support, security updates, regression testing, enhancement work, dependency management, user support and governance maintenance that follow. When organisations calculate the true total cost of ownership, internal builds routinely cost ten to twenty times more than the original estimate.
Why in-house builds create governance and audit risk
A financial crime risk assessment must be defensible. Regulators expect clear audit trails, transparent scoring logic, structured approvals, consistent application of methodology, documented assumptions, version control and evidence attached to each risk decision.
Most internal systems are never built with this level of rigour. Even when IT teams try to add these capabilities later, the effort becomes significant and introduces new risks. When auditors ask for a detailed history of who changed a control rating, why they changed it, when it was approved, and what evidence was used, internal builds often cannot produce the required traceability. This exposes the organisation to governance gaps, regulatory criticism and remediation programmes that far exceed the cost of purchasing a specialised platform.
Why it’s so difficult for IT to build a system MLROs can actually use
Financial crime risk assessments evolve constantly and consequently MLROs need the ability to adjust risk groups, risk categories, risk factors and risk indicators, change weightings, calibrate answer sets and answer set values, adjust inherent risk calculation techniques, risk scoring models, add, edit or remove controls and/or control tests, adjust control weightings, refine definitions, update workflow logic or add new jurisdictions without waiting for a multi-month engineering release cycle.
Internal systems rarely allow this flexibility because most logic is embedded in code, a short-cut in initial design thinking. This turns compliance into a customer of IT, rather than an empowered owner of the financial crime risk assessment framework.
Specialist RegTech platforms, like those developed over ten years by Arctic Intelligence and are designed specifically to avoid this dependency and deliver a multiple of the functionality, at a fraction of the cost, of developing in-house solutions. They allow MLROs and risk teams to configure, update and recalibrate the methodology directly, without writing code and without waiting in development queues. This capability is essential but extremely expensive to replicate internally.
There is no business case for an in-house build
There is ultimately no credible business case for building a financial crime risk assessment platform in-house, because internal development fails on every dimension that a sound commercial justification requires: cost, speed, capability, risk, and long-term sustainability. The true development cost, often several million dollars upfront and close to a million or more annually to maintain properly, far exceeds the price of mature, specialist platforms that deliver deeper functionality on day one.
For a simple illustration, imagine a financial crime risk assessment platform could be delivered in 1 year (as opposed to 5 to 10 for most advanced solution providers), that is 220 business days. To develop anything within such a short timeframe will require at least a team of ten, business and technical analysts (x2), UI/UX designers (x1), software developers (x2-4), software testers (x2-4), project manager (x1) and infrastructure specialists (x1) and that is not counting the countless hours needed from risk and compliance subject matter experts needed in designing a solution.
Now let’s assume the average daily rate is $1,000 (which is very conservative), that is 220 days x 10 x $1,000, which is $2.2 million. And in reality, what is going to be built, within a twelve month period, equates really to a maximum of 6 months development effort, assuming 3 months minimum in design (also conservative) and 3 months minimum in testing pre-release. A platform with six-months development will likely not be functionally rich and would need at least the same effort and cost over the next two years.
But let’s assume your organisation recruits superstars to the project and can deliver with half the team (5 people), that is still $2.2m in year 1 and $1.1m for the proceeding two years, bringing a conservative total cost of ownership over 3-years of ~$4.4m.
In comparison, assuming a RegTech’s annual license fee of $75k, which includes multiple users, expert-developed content, hosting, customer support, very rich functionality and quarterly updates and enhancements, the payback for an in-house build would take nearly 60 years, which makes zero commercial sense.
When organisations factor in lifecycle costs, opportunity costs, regulatory risk and the ongoing burden of maintaining specialist content and features the in-house approach becomes not only inefficient but commercially irrational.
In-house builds also often take years to develop, during which regulatory expectations evolve, key staff leave, and the organisation can be left exposed with outdated or incomplete tooling. More critically, in-house teams lack the specialised financial crime expertise needed to design, update, and validate risk models, controls, indicators, and methodologies – meaning the resulting tool is rarely regulator-ready, audit-defensible, or operationally reliable.
In short, building internally consumes far more resources, delivers far less capability and exposes the institution to far greater risk than simply adopting a proven, purpose-built platform – making the “business case” for in-house development effectively nonexistent.
The opportunity cost: what IT should be working on instead
Perhaps the most overlooked consequence of internal builds is the opportunity cost. When engineering teams are diverted into building and maintaining compliance tools, they are not focusing on initiatives that drive customer value, platform resilience, revenue growth, competitive differentiation, cybersecurity enhancements or digital innovation.
Every hour spent maintaining an internal risk platform is an hour not spent strengthening the organisation’s core business. Internal builds rarely advance strategic priorities, they displace them.
IT teams can build anything given unlimited time and budget. This dilemma is old. 10-15 years ago, many organisations would contemplate building their own transaction monitoring systems in-house but today rarely any organisations would even contemplate doing this as they have an appreciation for the complexity and in-time we believe they will come to the same realisation with financial crime risk assessment platforms.
Conclusion
Most organisations only recognise the true cost of in-house builds after years of sunk investment, shifting priorities, user frustration and regulatory findings. The in-house approach looks attractive from a distance – flexible, cost-efficient, fully controlled, fully bespoke but the illusion dissolves quickly under the weight of real-world requirements.
Forward-thinking organisations partner with specialist RegTech providers because they understand that speed, governance, defensibility, flexibility, scalability and total cost of ownership matter far more than initial build savings (which in itself is questionable). In practice, both IT leaders and MLROs share the same goal: a stable, scalable, adaptable and audit-ready platform that reduces risk and supports the business.
Internal builds rarely deliver this. RegTech platforms almost always do.
