A founder’s read on the numbers is usually the same. The vendor quote looks steep, the in-house build looks cheaper at first glance, and owning the IP feels like a competitive edge worth having. You may be sitting with exactly that proposal right now. The question worth asking before you commit to either path is what happens when the FCA or the SEC requests a walk-through of how the system makes its decisions.
That question does not come up in most generic buy-or-build guides. In a regulated financial services firm, it is the one that shapes everything else.
What is the buy-or-build decision in a regulated financial firm?
In an unregulated business, buy-versus-build comes down to cost, timeline, and whether the proprietary build creates lasting competitive advantage. In a regulated financial services firm, that calculation gains a third criterion. The system’s decision logic must be explainable and auditable on demand, which shifts the question from “what’s cheaper to build?” to “what can we defend when the FCA or the SEC asks?”
The FCA has been clear that AI in financial services must be actively supervised and understood, not simply deployed and monitored from a distance. The Bank of England’s framework for AI spells out seven required properties under the acronym TRUSTED. The system must be Targeted, Reliable, Secure, clearly Understood, supported with Ethical guidance, stress-Tested, and Durable. Each of those criteria requires documentation. A proprietary model built quickly to capture a first-mover advantage often runs ahead of the firm’s capacity to document it to that standard.
The EU AI Act strengthens this position for any firm operating in or connected to EU markets. AI systems used for credit scoring, AML, or fraud detection are classified as high-risk under Annex III, meaning they must meet specific transparency and human oversight requirements before deployment. A bespoke model built without those requirements in mind needs considerable rework before it operates legally in those markets.
Why does explainability change the calculation?
Many high-performing models built in-house optimise for predictive accuracy rather than interpretability. When a compliance officer or regulator asks why a transaction was flagged, a credit application rejected, or an alert generated, “the algorithm decided” is not a defensible answer. The Bank of England’s guidance for AI in financial services is explicit on this point, specifying that systems must be clearly understood and stress-tested before deployment.
The SEC has brought enforcement action against firms that made unsubstantiated claims about AI capabilities. Two recent cases, Global Predictions Inc. and Delphia USA, found that both firms had made false or misleading claims about their AI-driven investment processes. In each case, the firms could not adequately document how their systems reached their outputs. The inability to show their working was the core of the enforcement finding.
This matters directly for the build decision. A founder building a proprietary model to protect competitive advantage is, by design, making it harder for others to understand how the model works. That opacity protects the IP but compromises the explainability the regulator requires. Complexity that defends commercial advantage also obscures the decision trail, and at a regulated firm that is a genuine liability.
Where does the audit trail test actually show up in practice?
Three operational points are where explainability requirements become concrete. Anti-money laundering and transaction monitoring systems must be “reasonably designed to detect suspicious activity” under UK money laundering regulations and the US Bank Secrecy Act. Credit decisions affecting consumers trigger disclosure requirements in both jurisdictions. And any AI-driven regulatory reporting must be reproducible, with a clear record of what data the model used and why it reached its conclusion.
For AML specifically, the requirement goes beyond catching suspicious transactions. The system needs to produce output a human compliance officer can review and, if challenged, defend to a regulator. That means generating a rationale alongside the output, the specific factors that triggered the flag, in a form the compliance team can read and verify. A model without an interpretability layer cannot do this consistently without additional engineering, and that engineering needs to be designed in from the start.
Credit and lending decisions face an equivalent constraint. Consumer credit regulations in both the UK and the US require that any adverse decision comes with a specific explanation, generated at decision time as part of the model’s standard output. A vendor system built for a regulated market will have this as a standard feature. An in-house build has to design it in deliberately, and retrofitting it onto a model that was not built with interpretability in mind is expensive and often incomplete.
When does buying protect you and when is building justified?
For owner-managed financial services firms without a dedicated data science team, buying is the safer choice on two counts. Vendor-led AI projects succeed at roughly double the rate of internal builds at this scale, according to research on mid-market AI rollouts. More importantly for a regulated firm, established vendors in AML and fraud detection have already faced regulatory scrutiny. Their audit documentation, explainability reports, and compliance certifications exist and are ready to show a regulator.
Building makes sense in a narrow set of circumstances. The use case must be genuinely novel, the firm’s proprietary data must create an advantage no off-the-shelf vendor can replicate, and the team must have the capacity to design explainability into the model from day one. That is a high bar. For a firm in the 10-to-50 person range, it is rarely met, and the cost of getting it wrong falls on the firm’s licence to operate.
A founder’s argument for building often conflates two separate things. The data advantage is real. The model advantage tends to be claimed rather than demonstrated. Proprietary transaction data is genuinely valuable. Feeding it into a vendor platform that already has regulatory approval and a working audit trail frequently produces better outcomes than building a model from scratch and discovering its decisions cannot be explained on demand.
What should you ask a vendor before you sign?
Five questions separate a vendor that will help you pass regulatory scrutiny from one that will leave you exposed. Ask for documented decision logic, specifically output-level explanations your compliance team can reproduce at audit time. Ask which regulatory jurisdictions the product has been audited in. Ask whether the audit trail is exportable in a format your regulator can read. Ask about data residency.
The fifth question is the one that cuts through most clearly. Has the vendor’s model ever been challenged by a regulator, and if so, what happened? A vendor whose product has survived an FCA or SEC examination with the model remaining in production is a materially different prospect from one whose regulatory experience amounts to a well-written compliance brief.
On the build side, if the founder is pressing for it, the framing that tends to land is that the proprietary data is the asset worth protecting, and the decision model is where the regulatory risk sits. These two things can be separated. Proprietary transaction data can feed a vendor system that already holds regulatory approval, which means the IP argument and the compliance argument need not be in conflict. The firm keeps its data advantage while the vendor carries the explainability obligation.
If you are working through this decision and want a second view before you commit, Book a conversation.
